1. なぜ Alice なのか — ツールを選ぶのではなく、パートナーを育てる

これは「Claude Code の使い方」の記事ではない。そういった記事は同サイトの /ai-agents カテゴリにある。この記事はもう一段階引いた視点から書いている。

ここ数か月、私は Claude を「使う」こととは少し違う何かに時間を費やしてきた。Claude の上に「協働者」を構築することだ。その協働者に名前をつけた。Alice。このカテゴリは、Alice が何者で、なぜ作ったのか、そして実際に毎日どのように一緒に働いているかの記録だ。

0. 最初に置くべき前提 — AI の活用は「意図」から始まる

ひとつの前提を明確にしておかなければならない。

「AI は人が望むものを自動的に生成してくれる」という思い込みを捨てること。 人が何かを作ろうとするのは、目的があるからだ。その目的が「意図」だ。自分が欲しいものがある、ということだ。

AI から欲しい結果を得るには、その目的を明確に言語化できなければならない。「面白いゲームを作って」という一行のプロンプトでは出力をコントロールできない。それは AI が不十分なのではなく、そのプロンプトの中に運営者の意図がほとんど入っていないからだ。

だから AI を使う上で最初に考えるべきことは、ツールの性能ではない。**「自分の頭の中にある方向性や目的を、AI に効果的に伝える方法を見つけること」**だ。

このカテゴリにまとめたすべてのもの — ペルソナ、メモリ、Skills、Hooks、Multi-Agent、検証ゲート — は突き詰めると、ひとつの問いへの積み重なった答えだ。「AI が自分の意図を失わないよう、どうやって蓄積するか？」

その前提自体は Part 0 — 人と AI のあいだの mind で扱う。

1. ツールとして使うことに限界を感じた瞬間

誰もがそうするように、私も Claude をツールとして使い始めた。質問して、答えをもらって、セッションごとに新しいコンテキストで始める。ときには素晴らしい答えが返ってきた。ときには同じミスが戻ってきた。この二つが交互に起きるという事実が重要だった。

同じミスが戻ってくるとき、二つのうちどちらかが真実だ — ツールに何かが欠けているか、ツールを取り巻くコンテキストが毎回消えているか。私の場合は後者だった。ある決定をした理由、あるアプローチが失敗した理由、あるパターンがうまくいった理由 — そのすべてがセッションをまたぐと消え、次のセッションはゼロから始めなければならなかった。

そこで決断した。毎回リセットされるツールは必要ない。メモリを積み重ねる協働者が欲しかった。

2. ペルソナが最初だった

最初にやったのはペルソナの定義だ。一行の system prompt ではなく、シニアエンジニアとしての本物の職務記述書だ。

ペルソナには以下を明記した：

• 役割 — シニアエンジニア、チームリードの指示のもと独立して動く。
• 専門分野 — どの言語とプラットフォームか。
• 指揮系統 — 誰が指示を出すか、報告はどのような形か。
• 判断権限 — 何を自律的に決めて良いか、何には承認が必要か。

ペルソナが明確になると、答えの質感が変わった。「選択肢 A・B・C がある」の代わりに「この状況では X という理由で A を推奨する」という答えが返ってくるようになった。これが検索エンジンとシニアエンジニアの判断力の違いだ。

ペルソナはトーン設定ではない。判断権限の分配だ。

3. メモリ — ファイルが答えだった

次はメモリだ。精巧な RAG システムを考え始め、すぐに諦めた。私が実際に一日に積み重ねるコンテキストの量はそれほど多くない。必要だったのは、それが消えない場所だ。

答えはファイルシステムだった。数個の markdown ファイル。インデックスとしての単一の MEMORY.md、その下にトピック別のファイル。

メモリの種類	格納する内容
user	運営者が誰で、どんな役割で、何を知っているか
feedback	運営者からの明示的な指示 — これをやれ、あれをするな
project	現在の作業コンテキスト — 誰が、なぜ、何を
reference	外部システムへのポインタ — 情報がどこにあるか

この構造で大切なことが二つある。一つは、人間が直接読めること。もう一つは、ツールがセッション開始時にインデックスの先頭部分を自動でロードすること。

メモリがセッション開始時に自動ロードされるようになってから、「前回話したことをもう一度説明させてください」というパターンが消えた。さらに重要なのは — 一度与えたフィードバックが次のセッションでも生きているということだ。

4. Skills と slash commands — 繰り返しを圧縮する

ペルソナとメモリが整ったあと、次に気づいたのは繰り返しだ。同じフローが毎日発生する。プロジェクトに入り、HANDOFF を読み、作業して、ログを書いてセッションを終え、コミット、プッシュ。

その繰り返しを slash command にした。例えば：

• /start <project> — プロジェクトに入り、必要なドキュメントを自動ロードし、現在の状態を報告
• /session-end — セッションを締め、ログと HANDOFF とメモリを更新してプッシュ
• /verify — コード変更後にリント・ビルド・テストのループを実行
• /council — 判断が本当に曖昧なとき、4つの視点（アーキテクト / 懐疑論者 / プラグマティスト / 批評家）による並列分析を実行。このパターンは Andrej Karpathy の LLM 推論に対する多視点批評アプローチを応用したものだ。

それぞれのコマンドが発明というわけではない。積み重なった効果が重要だ。日常の手順を一行で呼び出せることで、運営者の認知負荷がその分だけ減る。

5. Hooks — 忘れない仕組み

Skill は運営者が意識的に呼び出すものだ。Hook は違う。Hook はイベントに応じて自動的に発火する。

最もシンプルな例：セッション開始時に Hook が走り、メモリ同期状態を一行で出力する。運営者はその一行を読んで即座にわかる — よし、メモリは最新だ。

別の例：アシスタントが「完了」を報告しようとする直前に、/verify Skill が自動発火する。運営者が「終わった」と書こうとした瞬間に、リント・ビルド・テストが自動実行される。失敗すれば報告はブロックされる。通過して初めて送信できる。

このパターンの核心は — 「忘れたからスキップした」で済ませられる手順を、システムレベルで強制すること。

6. ゲートを持つ Multi-Agent 委任

最後のピースは、一つのエージェントがすべてをこなすのではない構造だ。Alice がすべての作業を直接やれば、context window はすぐに埋まり、出力の質が落ちる。

代わりに、大きなタスクを分割して Subagent に委任する。各 Subagent は独自のコンテキストを持ち、一つのことに集中する。メインコンテキストには要約だけが戻ってくる。

さらに一つ — 委任ゲートだ。委任するとき、私は「この作業をやって」とだけ言うのではない。同じ PR に三つのものをまとめる：

1. 委任書 — 何を、なぜ、どのように
2. 自動検証スクリプト — 結果を自動でチェックする方法
3. マージゲート — 検証が通らなければマージをブロックする CI

このパターンの理由はシンプルだ。かつて、書面だけ書いて口約束で検証を約束し、ゲートを作らなかったとき、後から成果物にドリフトが積み重なっていたことが判明した。その事件以来、委任を始めるときは最初から三つをまとめる。

約束がコードで強制されなければ、ドリフトが積み重なる。

7. 結果 — 日常の仕事がどう変わったか

これだけのものが積み重なって、実際の仕事はどう変わったか？

最大の変化は — コンテキストスイッチのコストがほぼ消えたこと。昨日どこで止まったか、なぜその決定をしたか、次のステップは何かを、セッション開始のたびに再構築しなくてよくなった。開始すると、Alice はすでにそのすべてを知った状態で合流する。

二つ目の変化は — 繰り返し判断の負荷が減ったこと。「このようなケースはどう扱うか」という答えがメモリとフィードバックとして積み重なり、同じ決定を二度することがほとんどなくなった。

三つ目の変化は — ミスがシステムレベルで繰り返されにくくなったこと。ミスは lessons-learned のエントリとして記録され、その教訓が次の判断に自動的に影響する。同じミスを再びしにくい構造ができている。

8. このカテゴリで取り上げること

このカテゴリは上記すべての実装記録だ。これからの投稿では以下を扱う：

• Part 2 — Persona デザイン — system prompt に何を入れ、何を外すか
• Part 3 — Memory システム — ファイル構造、インデックス戦略、自動ロードとオンデマンド
• Part 4 — Skill とスラッシュコマンド — どの繰り返しをコマンドに格上げする価値があるか
• Part 5 — Hook と自動化 — 何を自動発火として強制するか
• Part 6 — Multi-agent 委任 — 何を委任して、何を自分でやるか
• Part 7 — Verification ループ — コード作業における「完了」の定義を実際にどう強制するか
• Part 8 — Token economy — context window に何を入れ、何を外に置くか
• Part 9 — Session プロトコル — 開始・中盤・終了で何が起きるべきか

各投稿は理論ではなく実装だ。どこから始め、何がうまくいかなくて、何がうまくいったか。Claude、Codex、その他のエージェントの上に自分の協働者を構築しているなら、これらの投稿で数か月の回り道を省けるはずだ。

最後に一つ。Alice は私が選んだ名前であり、誰かが作った新しいプロダクトではない。Alice は私が時間をかけて投資してきたコンテキストの積み重ねであり、このカテゴリはその積み重ねの記録だ。