AIが常に自分のことを知っている状態を作る — 作業実行エージェント編
前回はナレッジ基盤の話をした。
外の世界の知識と自分の文脈を蓄積して、AIが参照できる状態を作る設計だ。
この記事では、その知識を使いながら実際の仕事を回す「作業実行」の層に入る。
1つのセッションで全部やると何が起きるか
AIを使って仕事をしていると、こういう使い方をしがちだ。
1つのセッションを開いて、調査もして、設計もして、ドキュメントも書いて、レビューもする。
これがうまくいかない理由は、役割の混在にある。
「調査する」「設計する」「レビューする」は、本来まったく異なる思考モードだ。
調査は幅広く情報を集める発散の仕事。
設計は制約の中で最適解を絞り込む収束の仕事。
レビューは完成したものを批判的に見る評価の仕事。
これを同じセッションで混ぜると、AIのコンテキストが混濁する。
「設計しているのか調査しているのかどっちだ」という状態になり、判断の精度が落ちる。
さらに、長いセッションになるほど前半の文脈が薄れる。
1時間前に確認した制約事項を、AIは後半では曖昧にしか覚えていない。
役割ごとにセッションを分けて、専門の担当者に任せる——それが作業実行層の設計思想だ。
自分はPM、AIはチームという構造
役割を分けるとなると、次の問いが生まれる。
「何を自分がやって、何をAIに任せるか」
Orbitでの答えはシンプルだ。
意思決定は自分が持つ。実行はAIが担う。
要件の優先度、設計の方向性、成果物の品質判断——これらは自分の責任だ。
AIに任せると、文脈を知らない状態で判断が下されて、後から「なぜこうなった」が追えなくなる。
一方、「この方針で調査してまとめろ」「この設計でドキュメントを書け」「このドキュメントの論理的な穴を指摘しろ」——方針が決まった後の実行は、AIに任せた方が速くて精度が高い。
この役割分担を構造化すると「自分はPM、AIはチーム」という形になる。
チームの各メンバーは専門の役割を持ち、PMである自分が承認ゲートで意思決定する。
それ以外の実行・検証・集約はチームが完結する。
登場人物：3つの役割
Orbitの作業実行層には、役割の異なる3つのAIが登場する。
オーケストレータ
PMである自分と直接対話する司令塔。
依頼を受けてタスクに分解し、計画を立て、他の2つのAIにタスクを渡す。PMとのゲートもここで管理する。
会話の文脈を保持しながら全体を制御する役割なので、このAIだけは独立したセッションを持たない——自分との対話の中で動く。
実行エージェント
オーケストレータから「このタスクをやれ」というブリーフを受け取って、独立したセッションで動くAIだ。
調査・設計・ドキュメント作成など、タスクの種類によって使う「手札」を変えながら成果物を生成する。
オーケストレータの会話には関与しない——ブリーフを受け取り、成果物を返すだけ。
レビュアー
実行エージェントが生成した成果物を受け取り、独立した目で評価するAIだ。
「論理の穴はないか」「抜け漏れはないか」「リスクはないか」といった観点で検証する。
実行エージェントと同じ文脈を共有しないことが重要だ——作った本人には見えないバイアスを、第三者の目で拾う。
この3役が分離していることで、長いセッションでも文脈の混濁が起きない。
ナレッジ基盤がここでどう活きるか
前回の記事で作ったナレッジ基盤は、作業実行層の中で具体的に使われる。
タスク開始前の文脈注入
実行エージェントはコールドスタートする——オーケストレータの会話文脈を引き継がない。
だから、タスクの指示を渡すときに必要な知識を一緒に渡す必要がある。
ここでナレッジ基盤が使われる。
「このPJで過去にどんな設計判断をしたか」「このドメインでどんな知識が手札にあるか」をオーケストレータが引き出して、実行する際の指示書に含める。
手札スキルとしての参照
実行エージェントが成果物を書くとき、「どう書くか」の作法を手札から引く。
設計書なら設計書の書き方、比較分析なら比較の観点——タイプごとに引く手札が変わる。
この手札もナレッジ基盤の一部として管理している。
成果物からナレッジへの還流
タスクが完了したら、成果物の中に次のナレッジの種がある。
「なぜこの設計を選んだか」という判断記録（ADR）や、「この技術でうまくいった方法」は、そのまま手札として3_Wikiに追加できる。
この還流が積み重なるほど、次のタスクのブリーフがリッチになる。
仕事の流れを2フェーズに分ける
実際の仕事の流れは2つのフェーズに分かれる。
フェーズA：プロジェクトの立ち上げ
依頼を受けて、何をするかを決める段階だ。
オーケストレータと対話しながら依頼の内容を整理し、タスクに分解して、順番を決める。
ここで重要なのは「タスクの計画表」を作ることだ。
後続のフェーズはすべてこの計画表を読んで動く。
計画表が単一情報源になる。
フェーズB：タスクの実行サイクル
計画表を読んで、実行できるタスクを選んで、実行エージェントに渡して、レビュアーが検証して、結果を確認して、計画表を更新する——これを繰り返す。
1サイクルごとに計画が前進していく。
どこで人間が判断するか
2フェーズを通して、自分が判断するタイミングは3点だけに絞っている。
ゲート①：計画承認
フェーズAで作ったタスク計画表を確認する。
「何を・どの順で・どのレーンで（後述）やるか」に納得できたら進む。
ゲート②：実行前の確認
タスクを実行エージェントに渡す前に、オーケストレータが「こういう進め方でいいか」を確認してくる。ここで方針のズレを修正する。
ゲート③：計画の再分解
大きすぎて実行できないタスクに当たったとき、どう割るかをオーケストレータと一緒に決める。
この3点以外では止めない。
止めるたびにテンポが崩れる。
ゲートを絞ることが、AIチームを機能させる条件だ。
タスクの性質で実行方法を変える
すべてのタスクを同じ方法で実行するのは非効率だ。
Orbitでは2つのレーンを使い分けている。
自動レーン
他のタスクに依存しない・判断を必要としないタスク。
複数の実行エージェントを並列で動かせる。
「AとBとCを同時に調査してまとめろ」という指示で、3つのエージェントが独立して動く。
手動レーン
前のタスクの結果を受けて動くタスク、または判断を伴うタスク。
1つずつ確認しながら進める。
どちらのレーンに入れるかは、ゲート①の計画承認のタイミングで決める。オーケストレータが提案して、自分が承認する。
「これは並列でいける」「これは1つずつ見たい」という判断を自分が持つ。
レビューは成果物の「行き先」で深さを変える
実行エージェントが成果物を作ったら、レビュアーが検証する。
ここで一律に同じ深さのレビューをするのは非効率だ。
Orbitでは成果物の「行き先」でレビューの深さを決めている。
内部・使い捨て（調査メモなど）
レビューなし。自分がサッと確認して終わり内部・蓄積（設計書・Wiki化する知識）
レビュアーが論理の穴・抜け漏れを確認する外向き（提案資料・引継ぎ資料）
レビュアーの確認に加えて、必ず自分の目も通す
外向きの成果物をAIレビューだけで閉じないのは、品質の問題だけじゃない。
「受け手にとってどう見えるか」はAIには判断できない。
ここだけは人間が持つ必要がある。
自分で組むときに大事にしてほしいこと
この構造をそのままコピーしても、うまくいかない可能性が高い。
仕事の種類・タスクの規模・使うAIツールによって、適切なゲートや役割の設計は変わる。
大事なのは構造ではなく、設計のときに問うた問いだ。
「調査」「設計」「レビュー」の役割が混在していないか
自分が判断するタイミングは明確に絞れているか
ナレッジ基盤がタスクの文脈注入に使われているか
成果物の行き先によってレビューの深さを変えているか
これに答えを出した結果が、自分の作業実行ハーネスになる。
「また最初から説明している」がなくなる
3本通して書いてきた設計は、シンプルな問いから始まった。
なぜ、AIは毎回自分のことを知らないのか。
答えは構造にあった。
記憶の場所がなかった。
知識を積み上げる仕組みがなかった。
文脈を渡す経路がなかった。
①全体設計で、知識・文脈・実行の3層を分けた
②ナレッジ基盤で、外の世界の知識と自分の文脈を蓄積する場所を作った
③作業実行で、その知識を使いながら仕事を回す構造を作った
この設計を動かし始めてから、「また最初から説明している」という体験がかなり減った。
AIが自分の文脈を知っている状態が、セッションをまたいでも維持されるようになった。
ツールを上手く使おうとしていた頃は、毎回の対話をいかに上手く頼むかを考えていた。
今は違う。
AIが動くOSを自分で作るという発想に変わった。
OSが育つほど、対話の質が上がる。
説明コストが下がる。
AIが「自分を知っているチームの一員」として機能するようになる。
この記事を読んで「自分も作ってみたい」と思った人は、まずナレッジ基盤を構築するところから始めることを推奨する。
完璧な設計を最初から作る必要はない。
「外の知識」と「自分の文脈」を置く場所を作るだけで、AIとの対話は変わり始める。
