0. 人と AI のあいだの mind — 欲望のないプロセスとどう向き合うか

私が考える AI とは何か。頭脳は非常に優れているがドメイン知識が不足している人のような、欲望のないプロセスだと思う。だからこそ AI を使って自分が望む作業を遂行するには、AI に自分が望むことを正確に伝えることが重要になる。人のように一つ二つを抽象的に提示したからといって、AI は人と同じように考えるわけではなく、人が期待する形で作業を進めてくれるわけでもない。

AI を使う人が陥りやすい最も簡単な罠が、まさにこの点だ。AI は演算と推論のために非常に優れた頭脳を所有している。だが正確な入力値と目標が提示されなければ、運営者の意図とは異なる結果物を作り上げてしまうこともある。この間隙は、運営者が頭の中に持っている期待と、AI が演算と推論を始める時点で持っているデータが違うところから来ている。したがって AI を通じて運営者が望む結果物を得るためには、AI の動作原理をよく理解し、運営者の考えが明文化されて AI に漏れなく伝わるようにすることが最も大切だ。「こんなことまでいちいち説明して定義しなければいけないのか」と思うほど詳細な記述だけが、AI を脇道に逸れさせない唯一の良い方法だからだ。

このような理由から、当初はプロンプティング技法と方法に関する数多くの講義があった。以前は会話のすべてが散文だった。もともとは運営者が握れる唯一のレバーが次のプロンプトだけだった。その後、Skill や Hook のような自動化されたプロセスで AI と人の間隙を縮める方法が人気を集めた。さらにその後、ハーネスのように目標とする道から AI が外れないようプロセスで制御する方式が力を得てきた。AI を効率的に使うためのこうした様々な方式は、結局のところ限られたメモリの中で運営者が望むことを最も正確に表現して曖昧さをなくし、目標とするものを正確に打ち込んでおくために必要なものだと考える。

積み重なった四つの層

ここ数年この分野が実際にやってきたことは、私から見れば層を交換したのではなく累積したものだ。新しい層が入ってきても以前の層はそのまま残り、運営者が意図を表現できるレバーが一つ増えるだけだからだ。

1. Persona — 協力者の役割・トーン・既定値を固定する単一のシステムプロンプト。Part 2 — Persona 設計で扱う。
2. Skill とスラッシュコマンド — 繰り返される手順に名前をつけて、運営者が段落ではなく語彙で呼び出せるようにする。Part 4 — Skill とスラッシュコマンドで扱う。
3. Hook — 同じ手順をシステムが適切な瞬間に自動発動させ、運営者が覚えていなくてもよいようにする。Part 5 — Hook と自動化で扱う。
4. ハーネス — 運営者が見ていないときも AI を目標の道の上に縛りつけておくランタイムレール。検証ループ、リリースゲート、Ralph ループなどがここに属する。

新しい層が以前の層を無用にするからではなく、各層が同じ間隙の異なる失敗様式を扱うからだ。プロンプティングは依然として persona の中で起きる。Skill は依然としてプロンプトで呼び出される。Hook が Skill を呼び出す。ハーネスが Hook を発動する。累積であって代替ではない。

"漏れなく渡す"とは実際にどんな姿か

具体的な例を一つ。/verify とはつまり何だろう。ある「完了」報告の直前に 7 段階の検証ループ(lint・build・type check・test・security・diff 点検・報告整合)を回す Skill だ。運営者がスラッシュコマンドで明示的に呼び出すこともできるし、アシスタントが「完了」という単語を出力する直前に Hook が自動的に発動させることもできる。同じ手順、二つの入口。Part 7 — Verification ループで詳しく扱う。

その Hook がなければ、間隙はそのまま露わになる。アシスタントがビルドが壊れた状態で「完了」と報告してしまう。完了報告とビルド実行は別々の二つの行為であり、運営者が頭の中で持っていた「完了とはテスト通過までを意味する」という mind がどこにも明文化されていなかったからだ。Hook があれば、アシスタントが覚えているかどうかに関係なく手順が発動する。運営者の意図 — 「完了 = 検証された状態」 — が頭の外へ出て、運営者なしでも回る機械の一部に移ったわけだ。

Loading diagram…

mind 自体が変わり続ける

AI がいくら発展して性能が向上しても、運営者の意図を先回りして察知し、運営者が満足する結果を作り出すのは難しいだろうと考える。運営者の欲望や満足度や目標が変わり続けるためだ。朝には海が見たかったとしても、夕方には山が見たくなるかもしれない。

mind が動く標的なのであれば、規律は運営者を予測することにはなり得ない。運営者の現在の状態を読むコストを低くすることでなければならない。PRD を単一の真実の源として扱う理由がそれだ。一度きりの仕様ではなく、目的地が変わるたびに運営者が更新する生きた宣言として扱う。Part 10 — PRD を単一真実源としてで扱う。

PRD が目的地に対して果たす役割を、persona と Skill は方法に対して果たす。運営者が「実は冗長なステータス更新より簡潔なほうが好みだ」と気づいたとき、persona を書き直す。書き直した内容は以後すべてのセッションが見られる。mind が頭の外に移って、次のセッションがそれを見つけられる場所に置かれる、ということだ。

シニア開発者にとってより意味がある理由

私のようにソフトウェア開発者として長い時間働いてきた開発者にとって、いまの AI 技術は非常に魅力的だと思っている。数多くの設計とアーキテクチャを商用で扱ってきた立場から、大きな絵を描き、そこに必要な要素を AI に委任して、短時間で望むシステムを構築できるからだ。以前は各開発者に説明し、作業を分担させ、結果物を取りまとめ、システムが動くように構成する作業を、いまでは AI Agent がほとんど代行してくれる。変化の本質は AI が開発者を代替するということではなく、明瞭なメンタルモデルを持つシニア開発者が非常に小さなチームで完成度の高いシステムをリリースできるようになったことだと考える。意図伝達コストが崩れ落ちたからこそだ。

PRD と TRD をうまく構成して設計を作り、それに沿った具体的な実装計画を非常に小さな単位に分割して遂行できるようにし、要素ごとにゲートを立て、最終段階で commercial release gate にチェックさせるようにすれば、かなり完成度の高いシステムを少人数で開発できるようになったわけだ。

このシリーズが続いていく先

このカテゴリの残りの記事は、積み重なった各層を一つずつ歩いていく。出発点は、協力者に名前をつけた理由だ。次の記事 — Part 1 — なぜ Alice なのか — はその個人的な版になる。Claude をツールとして使う方式がどこで崩れたのか、persona・メモリ・Skill・Hook・検証ゲートがどう累積していまの私が Alice と呼ぶ日常のパートナーになっていったか、というところを扱う。