MacのPDFビューアーを自作する計画と、計画書レビューを必ず通す運用に戻した記録

Mac で PDF をクリックすると、ブラウザのタブが開く。 見るたびにそうなるので、ずっと引っかかっていた。 有償の PDF ソフトの簡易版でいいから、手元で PDF を操作できるアプリを作ることにした。

環境を測ってから計画書を書かせる

リポジトリ置き場の直下に独立したプロジェクトとして立てる、という前提だけを渡した。 最初にやらせたのは、Xcode と Swift と Rust が手元に入っているかの確認だった。 候補を机上で並べても、動く保証のないものは選択肢にならない。 実測で残ったものだけを材料にして、計画書を書かせた。

計画書は決裁フォーム付きで HTML に変換させ、Chrome の前面タブに出させた。 図と表と回答ボタンが崩れていないことは、スクリーンショットで確認させた。 ここまではいつもの型どおりに流れていた。

レビューを通した記憶がない

画面を眺めていて引っかかった。 この計画書、Codex のレビューを通していないのではないか。

通っていなかった。 理由を吐かせると、ルールファイル（~/.claude/rules/plan-codex-review.md）が 2026-07-02 に「大規模・不可逆な計画のみレビュー必須」へ緩和されていた。 今回はその条件に当たらないと判断してスキップした、とのことだった。

判断そのものは筋が通っている。 数ファイルで可逆な変更しか含まない計画に毎回外の目を入れるのは重い、と考えて条件を絞ったのは自分だ。 ただ、そのとき頭にあったのは実装作業のほうで、計画書ではなかった。 計画書は方針を固める文書で、ここが曲がったまま通ると後続の工程が全部その方向へ走る。 しかも規模で線を引くと、線の内側かどうかを判定するのは実行側になる。 今回まさに「該当しない」と自己判定されて飛んだ。

「計画書は規模を問わず必ずレビュー」に戻させた。 そのうえで、今回の計画書もその場でレビューに投げさせた。

ルールとスキルでは効き方が違う

直させながら、もうひとつ気になった。 決裁フォームに4件の未回答が並んでいる。 回答が届いたら計画書に反映する。 この一連の流れは、どのファイルが定義しているのか。 ドキュメント作成のスキル側に書いてあるほうが自然にも思えたので、そこも含めて聞いた。

答えは ~/.claude/rules/decision-form.md で、スキルではなくグローバルルールだった。 ルールは常にコンテキストへ読み込まれる。 スキルは明示的に呼んだときだけ中身がロードされる。 確実に効かせたい手順は、ルール側に置くほうが強い。

今回レビューが飛んだのも、同じ構造の裏返しだった。 ルールに書いてあったから、条件分岐そのものは確実に読まれていた。 ただ、その条件が緩かったので、緩いまま実行された。 ルールは書いたとおりに効く。

宛先が変わると前提も変わる

Codex のレビューを2巡させ、指摘を反映した計画書を画面に出し直させた。 そこで自分の前提のほうが揺れた。 Windows 機には有償の PDF ソフトが入っているし、Mac にも同じものを入れれば今日で解決する。

ただ、自作すれば人に渡せる。 相手が有償ソフトを契約していない場合、渡せるかどうかが効いてくる。 配布を前提にすると要件が変わるので、配布の設計も計画書に足させた。

本当の宛先は父の Mac だと、その場で言葉にした。 毎回ブラウザに引かれていく挙動を、父の側でも止めたい。 そのうえで聞いた。 そもそも無料のアプリで開けるのではないか。

返ってきた答えは、OS 標準のプレビューが最有力というものだった。 父の Mac にも最初から入っていて、無料で、広告も出ず、見開きも表示できる。 既定アプリをそちらに変えるだけで、「ブラウザで開く」は今日直る。 他の候補は、UI が古風で一般ユーザー向きではないオープンソースのビューアーと、閲覧は無料でもログイン誘導と有料版の案内が出る大手のリーダーくらいだった。

つまり自分が解きたかったのは「PDF が開けない」ではなかった。 父が迷わず使える形まで細かく寄せたい、という問題だった。 既製品で足りないのはその一点だけで、そこは自作でしか埋まらない。 この比較ごと計画書に書かせた。

決裁4件を受けて、実装へ

決裁フォームから4件の回答が届いたので、計画書に反映させた。 3巡目のレビューを回してから、骨格の実装に入った。 最初のウィンドウが開いて PDF が表示されるところまでは、この日のうちに動いた。

そのあとで、父の Mac はまだ買っておらず Apple Silicon の新機になる予定だと伝えた。 それだけで arm64 ビルドだけで足りることになり、複数アーキテクチャ対応のフェーズが着手前に消えた。

学び

• 計画書のレビューは規模で線を引かない。実装は小さくやり直せるが、方針を間違えた計画書は後続の工程を全部連れていく
• 規模を条件にすると、条件の判定そのものが実行側の自己申告になる。判定を渡したくない手順は、条件を付けずに書く
• 必ず守らせたい手順はスキルではなくルールに書く。スキルは呼ばないと読まれない
• 「誰に渡すか」を先に言葉にすると要件が減る。父の機種が決まっただけで、フェーズがひとつ消えた