モバイルアプリ開発者 · Android & Flutter
補足： 本記事は AI（Claude）が私の最初のメモと着想をもとに仕上げたものです。
最近、自分の AI エージェントの回し方を整理していて、ずっと見て見ぬふりをしていた問いに気づいた。エージェントの状態は、いったいどこに置かれているのか？
たいていの場合、それはチャットウィンドウの中にある。デスクトップ app で会話を開き、機能について話し合うと、エージェントが計画を立て、コードを書き、バグを直す——その作業の文脈すべてが、あの流れていくメッセージの列に乗っている。自然に聞こえるが、その列は意外なほど脆い。
デスクトップチャットには、生まれつきの制約が三つある。
つまりチャットウィンドウは RAM だ——速くて便利だが、電源が落ちれば消える。それなのに私たちは、ワークフロー全体の状態を RAM に置いている。地に足のついた居場所も、他人が読める場所も、セッションを越えて生き残るものも、何もないままに。
私の解決策は、突き詰めれば単純だ。エージェントの状態をチャットに残さず、issue tracker のコメントスレッドへ持ち上げる。
すべての計画、すべての問い、すべての裁定が、チケット上の一つのコメントになる。私は自分の Claude Code 設定（skadi という名前）に、こう一つだけ掟を定めた。「スレッドこそが記録。横道はなし。」チャットはエージェントと話す場所、チケットは状態が実際に置かれる場所だ。
YouTrack でも Jira でも、あなたの使うものなら何でもいい——チームはもともとその場所を信頼している。履歴があり、権限があり、通知があり、誰もが見られる。エージェントのワークフローをそこに結びつければ、永続性・監査可能性・セッションをまたぐ継続性・複数人での協働が、ただで手に入る。
ここから先は三つの段階——計画（plan）、鍛造（forge）、レビュー（review）。それぞれが小さなマーカーを、段階と段階のあいだ、そして人と機械のあいだの契約として使う。
最初の段階は計画だ。/council を走らせると、サブエージェント（私は Erestor と呼んでいる）が送り出される。チケット全体を読み、計画を草案し、そのままコメントとして投稿する。先頭に [PLAN] のタグを付けて。
そして止まり、私の裁定を待つ。読み終えたら、[APPROVE]（承認、進め）か [REJECT]（差し戻し）で返す。
ここで肝心なのは、承認そのものがコメントであって、チャットの一行ではないということ。今日草案させて、明日になってから承認しに戻ってもいい。Erestor は読み、草案し、問うだけ——私の代わりに決めることはない。skadi の言葉でいえば「Erestor は謀り、Elrond が決める」。あらゆる可否の関門は人の手に残り、その関門はチケットに書き込まれて、会話とともに流れ去ったりしない。
計画が承認されたら、第二の段階は鍛造だ。/celebrimbor を走らせると、最初にするのはそのスレッドを読みに行くこと——[PLAN] とその [APPROVE] を見つけ、計画が草案され、かつ承認されたことを確かめる。
それから計画を実装し、ドラフトの PR/MR を開き、PR の URL をチケットへ戻して投稿する。[FORGED] のタグを付けて。
この一歩こそ、私にとってこの設計の眼目を言い表している。鍛造段階の入力は、それ自身がスレッドから読み取ったものだ——計画を立てたときのチャットは、もう必要としない。 計画と鍛造は、まったく別のセッションでも、別の人でもかまわない。skadi はこう記す。「スレッドは依然として記録。PR の URL は [FORGED] としてチケットへ戻り、謀議と鍛造は歩調を合わせ続ける。」
第三の段階はレビューだ。道具は二つある。
/mithrandir は多軸の評定を走らせる——安定性、性能、スタイル、保守性、正しさ——そして一つの結論に収束する。Merge、Hold、それとも Refuse。/narvi は PR 上のコメントに答える。コメント一件につき commit 一つ、一つひとつの指摘をコードに変えていく。これらもまた、チケットと PR に乗る。レビューは誰かの頭の中に閉じた判断ではなく、読み返せて辿り直せる記録になる。
マーカーを並べてみると、それが一つの状態機械であることが分かる。
[PLAN] → [APPROVE] → [FORGED] → [METTA]
計画草案 人が承認 PR を開く マージ済み
（あいだに小さなマーカーもある。[REJECT] で差し戻し、[SKELETON] で先に骨組み、[BASE: branch] で基底ブランチを指定。）
マーカーそのものは平易な言葉だ。トールキン『指輪物語』の裂け谷（リヴェンデル）の会議から借りているのは、/council や /celebrimbor といったコマンド名のほう——味付けであって主菜ではない。本質はこうだ。どのセッションも、どの段階も、そのスレッドを読むだけで「いまこの作業がどこまで来たか」を再構築できる。 状態は誰の頭の中にもなく、閉じれば消えるウィンドウの中にもなく、チケットの上に、白地に黒で記されている。
状態がチームのもともと信頼する基盤に乗ると、チャットウィンドウに閉じ込められていたものがほどけていく。非同期（今日計画し、明日承認し、明後日鍛造する）、セッションをまたぐ（新しいマシンでも新しい会話でもそのまま続く）、複数人（チームメイトが読めて、レビューできる）、監査可能（どの一歩も痕跡を残す）。スイーパー（skadi では /glorfindel や /rhovanion）に全チケットを定期的に巡回させ、マーカーから先へ作業を押し進めさせることさえできる——引き継ぐ者が必要とするものは、すべてすでにチケットの上にあるのだから。
一つはっきりさせておくと、この方法はいまのところ小さなタスクでしか検証していない——範囲が明確で、一つ二つのファイルで片づく類のものだ。大きなタスクになると摩擦が一気に増える。計画そのものの精度が足りず、鍛造段階がそれをなぞると逸れていく。大きな仕事にもこれを効かせるには、まだ欠けている一片がある——計画の内容の精度を磨き上げる、何らかの仕組みだ。それは次の一歩で、いまはまだそこに届いていない。
というわけで、これがいまの私の進め方だ。エージェントの状態をチャットに残さない。 チームがもともと信頼する基盤——issue tracker——へ持ち上げ、小さなマーカー・プロトコルを、段階と段階のあいだ、人と機械のあいだの契約にする。チャットは RAM、チケットはディスク。計画をチケットに書けば、状態はようやく、地に足のついた、他人が読めて、セッションを越えて生き残る居場所を得る。