決める役と作る役を、なぜ分けているか

ぼくはコードを読めません。それでも、AIが作ったものを公開してよいかどうかは、自分で決めています。

今朝、Xでこう聞きました。「コードを書かない人が、AIに作らせたものを承認するとき、何を見て承認していますか」。ぼくの答えは、指示書と、返ってきた報告の5項目です。コードは見ていません。それで回っている理由を、4本に分けて書きます。1本目は、そもそもなぜ2つのAIに分けているか、です。

ぼくの体制

使っているAIは2つです。

決める側: チャットのAI。ぼくの相談相手で、何を・なぜ・どこまで作るかを日本語の「指示書」にする
作る側: コードを書くAI（ぼくはClaude Codeを使っています）。指示書を読んで実装し、公開の直前に一度だけ止まって報告する

ぼくの仕事は3つだけです。決める側と相談する。出てきた指示書を読んで、作る側に貼る。報告を読んで、承認するか直すか言う。

ぼく ⇄ 決める側（チャット）
          ↓ 指示書（日本語）
       作る側（コードを書くAI）
          ↓ 報告（変更ファイル／前提の確認結果／要確認と根拠／検査の結果／実物の所在）
ぼく → 承認 → 公開

最初に分けた理由

正直に言うと、最初は理屈より感覚でした。

人の組織でも、企画する人・設計する人と、実行する人は分かれていることがほとんどです。実行役にぜんぶ担わせるのは無理があると思っていたし、そうすると漠然と間違った方向に進む気がしていました。それに、チャットとコードを書くAIは、そもそも動く場所が違います。こういうふうに使うものなんだろう、と勝手に考えて、2026年8月9日にこのサイトを作り始めた日から分けています。

もしチャットのAIが実行役も兼ねていたら、分けなかったかもしれません。

分けてみて分かったこと

1か月使って、感覚だった理由が5つの実感になりました。実感の順に書きます。

1. 判断が自分に残る
コードは読めなくても、指示書は読めます。「何を・なぜ・どこまで」が日本語で書いてあるので、意図が合っているかは自分で判断できる。承認の対象がコードから指示書と報告に変わったことで、最終判断を手放さずに済んでいます。

2. 2つのAIが互いに反証する
決める側も間違えます。作る側が指示書を読んで「前提とファイルの実物が違う」「材料が無い」と止まると、決める側の間違いがそこで見つかる。逆に、決める側が「その頼み方は前提がおかしい」と言うと、ぼくの間違いが実装の前に見つかる。AIが1つだと、決めるのも作るのもできたと言うのも同じAIで、間違いが中で完結してしまいます。

3. 自分の理解が深まる
指示書と報告を毎回読むので、コードは読めなくても「いま何をしているか」は分かるようになりました。1か月前より、自分のサイトの仕組みを説明できます。

4. どこで外れたか分かる
うまくいかなかったとき、指示書と報告を照らすと「決め方が悪かった」のか「作り方が悪かった」のかが切り分けられます。AIが1つだと、これができません。

5. 記録が残り、時間を分けられる
指示書は文書として残ります（2026年9月9日時点で14本）。決めるのはセッションの中で、作るのはセッションの外で貼るだけ、と時間も分けられます。

この体制でないやり方は、もう怖くてできません。1つのAIと1対1でやっていたら、望んでいたものの100％はできていなかったと思います。

ただし、分けただけでは反証は起きない

ここが、この続きものでいちばん言いたいことです。

作る側が止まってくれるのは、体制を分けたからではありません。「前提を実際に読んでから作る」「無いものを参照されたら推測で補わずに止まる」「分からない値は［要確認］にする」という決まりが、作る側の設定ファイルに書いてあるからです。決まりが無ければ、実行役は黙って作ります。

同じことが決める側にも言えます。「材料はファイル名で指定する。『添付』『前のメッセージ』と書かない」という決まりが無かったころ、渡したつもりのものが届かない事故を、ぼくは1か月で5回起こしました（8月30日、8月31日、9月5日、9月9日に2回）。分業の弱点は、いつも引き継ぎです。

だから、この型の中身は「決まり2本」です。決める側のAIに最初に1回貼る決まりと、作る側の設定ファイルに1回貼る決まり。この2本を、ツールとして公開しました。中身は2本目・3本目で1行ずつ説明します。

今朝の実物

体制が動いた例を、今日のものから1つ。

今朝、毎朝動く自動処理が止まっていました。原因は、前日ぼくが新しいファイルを git add の一覧（機械が保存する対象の一覧）に足したとき、そのファイルが .gitignore（保存しないファイルの規則）に当たっていることを確かめていなかったこと。決める側に状況を貼ると、原因の候補と確度を分けて出してきて、指示書になりました。作る側に貼ったら、こういう報告が返ってきました（一部を抜粋。画像は報告の原文です）。

① check-ignore の結果
29行目の包括規則 data/* に当たっていました。同じブロックに他のファイルの例外はあり、own_posts_x.json だけ例外が無い状態でした。
② 台帳の設計判定: 蓄積型。前回以降の差分だけを取得し、既存の記録に新規分を足して保存します。毎回全件を書き直す設計ではないので、ファイルをコミットして引き継ぐ必要があり、指示どおり修正しました。
③ 差分
・.gitignore に例外を追加（理由のコメントつき）
・git add 一覧にある全パスに check-ignore を当て、NG は0件でした
・開発規約への追記として「git add 一覧にパスを足すときは git check-ignore で確認する」
承認で push します。

check-ignore は「このファイルは保存しない規則に当たるか」を調べる命令、コミットは変更を記録として確定させる操作です。

ぼくが見たのは、この報告だけです。コードは見ていません。「原因はここ」「このファイルは引き継ぐ必要があるから、こう直した」「他に同じ穴は無い」「同じ失敗を防ぐ規約を足した」が日本語で書いてあるので、承認できました。

止まったのは失敗ですが、直し方が記録に残ったので、同じ穴には落ちません。

この続きものの残り

第2本: 決める側の決まり（チャットのAIに貼る文と、なぜその行があるか）
第3本: 作る側の決まり（設定ファイルに貼る文と、なぜその行があるか）
第4本: ぼくの1日の使い方

このツールを公開しました（2026年9月11日）

記事に出てきた「決まり2本」を、「Code指示書の型」の名前で公開リポジトリに置きました。中身は Markdown のテキスト2本と README だけです。

chat_side.md ── チャットのAI（決める側）に、最初に1回貼る決まり。以後、作業はすべて「指示書」の形で出てくるようになります
claude_md_block.md ── 作業リポジトリの設定ファイル（CLAUDE.md）に、1回貼る決まり。材料が無いときに作らず止まる・分からない値を推測で埋めない・公開の直前に1回だけ止まって報告する、という動きになります

テンプレートや記入例は入れていません。ぼくの環境で確かめた結果（2件）と提供条件（MIT・保証なし）は README に書いています。

→ hitori-ai-factory.com/tools/code-brief
→ github.com/mhitori/haif-tools/tools/code-brief

2026-09-11 表示を修正（引用の段落分け・ツールの案内節を追加）
2026-09-18 追記: 図1（3者の関係図）を加えました。本文は変えていません。