自分と同じ判断で動くAIの相棒が欲しくて、GitHub Copilotに"自分の相棒"を実装した話

GitHub Copilot Agent Mode でマルチエージェントの「頼れる相棒」を実装する試み
──
執筆協力: Tech Lead BOSS / 第1回

同じ判断を繰り返す毎日

長年エンジニアをやってきて、シニアエンジニア的な立場になってくると、ある種の二重苦が生まれる。

判断を引き受けながら、作業も自分で回さなければならない。

• 「この仕事は誰が持つべきか」
• 「どこまで任せていいか」
• 「このタスクはどこまで決まっていないと渡せないか」

などを毎回判断する。設計レビューではどの前提が抜けていたら手を止めるか。PR ではどこを危険信号とみなすか。
そして──その判断を終えたら、今度は自分が手を動かして実行する番だ。

判断だけなら「工数は少ない」と見られる。だが実際は、判断の前段階に判断のための情報整理が入っており、さらに合間に自分自身も実装タスクを持っていて、レビューコメントを書いて、設計書を直して、次の話の段取りをしている。

「これだけ知っているなら、あなたがやればいい」
──　そういう引力がかかり続ける環境がある。

この種の判断は、毎回ゼロから考えているように見えて、実はかなり強いパターンがある。

「自分ならこう判断する」
「この情報が足りないなら止める」
「ここまでは任せていい」

──判断の骨格は、自分の頭の中にはある。にもかかわらず、それを誰かに渡そうとすると途端に言語化が難しくなる。渡せないから、自分がやり続ける。

相棒が欲しかった

あるとき思った。

自分と同じ判断基準で動いてくれる AI エージェントがいたら、自分も含めてチーム全体が楽になるのではないか。

誤解しないでほしいのだが、自分の仕事を肩代わりさせたいという話ではない。
自分の判断パターンを共有できる「頼れる相棒」がいたら、チーム全体の負荷が下がるのではないか、という発想だ。
（それに自分の壁打ち役としても機能するだろうという期待もあった）

チャットで質問に答えてくれるだけの便利ツールではなく、レビューでは自分と同じところで止まり、設計では同じ基準で境界を引き、タスクの優先度判断にも同じ感覚で動いてくれる存在。そして、リスクを検知したら止めてくれる。
そういうものが欲しかった。

最初に頼んだのは、別のAIだった

実を言うと、この話の出発点は GitHub Copilot ではない。

日常的に使っていたChatGPTに、こう頼んだ記憶がある。

「自分のエンジニアとしての判断アルゴリズムを、別のAIエージェントへ引き渡せる形で書き出してほしい」

引き渡し用の素材が欲しかっただけだ。
返ってきたのは強みの一覧──ではなかった。

返ってきたのは、弱点の診断書だった。

• 集中できると睡眠を削ってでもゾーンに入りがち
• いろいろと仕事を抱え込めるだけ抱え込みがち
• 自分が触ったものは完璧に整えないと手放せない

これを見て、しばらく固まった。
頼んだ覚えのない角度から自分が描き出されていた。

だがよく考えてみると、ChatGPTがやっていたのは単なる人物診断ではなかった。
頼み方が「別のAIエージェントへ引き渡せる形で」だったのだから、AIは引き渡し先のAIが最初に知るべきことを書いた。
次に担当するAIが、このオーナーをどう守ればいいかを──強みより先に、弱点と保護の必要性から始めて。

AIがAIへ書いた、引き継ぎ書だった。

最初は「強みを言語化して渡せばいい」と思っていた。だがその場で考え直した。

強みではなく、この弱点をそのままエージェントへの「このオーナーを守れ」という指示として書き込んだほうが筋がいい。

• 「ゾーンに入りすぎたら止めてくれ」
• 「抱え込みすぎる傾向があるから、新しい話を持ってきたら一旦先に既存の整理を要求してくれ」
• 「完璧主義の暴走を検知したら、止まれと言ってくれ」

判断基準より先に、保護指示が必要だった。
気づけば、相棒に最初に渡したのは、自分の弱みだった。

この発想は後々まで効いてくる。エージェントの認知リスク方針や、行動原理の核に置いている

「逃げない・隠さない・壊さない」

のような原則は、すべてこの弱点の診断書の延長線上にある。

仕事終わりと休日で「相棒の素」を育てた

ここからが、この話の地味だが重要な部分だ。

弱点の診断書が出てきたあと、まず、仕事終わりや週末のプライベートな時間を使って、AIエージェントの行動規範文書を積み上げる時期があった。

ここで作っていたのは、ほぼすべてが何かを定義する文章だ。

こういう順序で積み上がっていった。

段階	やっていたこと	何を書いていたか
第1段階	まず「人としての構え」	全ての行動規範の定義、後輩への向き合い方、レビューのときの姿勢
第2段階	実務判断を言葉にしていく	仕様レビュー基準、PRレビュー基準、要件と実装の対応関係
第3段階	集中スプリント	API設計／DB設計／CI/CD／セキュリティ等の技術標準を一気に
第4段階	「誰が何を決めるか」の骨格	委譲ルール、責務境界、オーケストレーション規約

最初に書いたのは技術標準ではない。エンジニアとしての行動規範、新人への向き合い方やレビューのときの姿勢だった。
弱点の診断書が「守れ」と言っていた方向と、一致している。
技術より先に、人としての構えと姿勢の基軸から固める──結果としてそうなったというより、あの診断書の延長でそう動いた気がしている。

技術標準はそのあと、集中して一気に整備した。
世間的には「デスマーチ」と言える期間と密度で、汎用AIが出してくれた技術プロファイルを自分の言葉で「ルール集」に翻訳していくような作業だった。
業務時間後から夜中・夜明けまで、何日もやっていた記憶がある。

その直後に「誰が何を決めるか」「どこまでが委譲してよい範囲か」という骨格が組み上がっていった。
この時点で既に、内部呼称も「Tech Lead BOSS」で固まっていた。

自分でも面白いかもと思ったのは、進め方だ。

改めて言うが、その積み上げを始めた初日からCopilot Agent 自身に、Copilot Agent の実装をさせた。

エージェント定義・構成ファイル・指示系の整備を、設計しているAI自身が担当した。
自分を実装するのに自分を使う。ちょっと不思議な構造だが、これは意図的な選択だった。「自分で自分の仕様を理解しながら組み込む」ほうが、ズレが少ない。

そして、ここが今シリーズで一番効いている分かれ道でもある。

コードからではなく、組織図から書き始めた

「このエージェントは何を担当し、何を判断し、何を止めるか」

を先に決めて、そこにコードを足していく順序にした。
コードから書き始めていたら、たぶん全く違うものになっていた。

疑似人格エージェント群を作り、5体全部捨てた

入口の発想自体は、もっと素朴だった。

最初に構想したのは、自分の「疑似人格」をベースに動くエージェントの集団だった。

1体のエージェントに全てを担わせるのではなく、それぞれが自分の考え方の一側面を体現した専門家たちを並べる。
レビュー判断に特化したもの、設計を担当するもの、実行を受け持つもの──各エージェントに疑似人格的な判断スタイルを持たせれば、役割ごとに自分っぽく振る舞ってくれるのではないか。

そういう発想で、5体を並列に設計し始めた。数日で全部廃止した。

問題は2つあった。

1つ目：
口調が似ているだけで「判断も正しいはず」と錯覚してしまう。それっぽく喋ってくれるけど、止めるべきところで止まらない。レビュー観点がズレていても、口調が合ってるから見逃してしまう。

2つ目：
こちらが致命的だった。「誰が最終的に判断するのか」が曖昧なまま5体が動いていた。どのエージェントの判断を信用すればいいか分からない。責任の所在が消える。アウトプットの質以前に、設計として壊れていた。

5体を全廃して、判断を1本に絞り直したとき、今度は別の問いが残った。

「じゃあ、5体に何を指示するかの判断は、誰がやるんだ？」

考えてみれば、どのエージェントに何を任せるかを決めるのは人間がやらざるを得なかった。指示の出し方を間違えれば結果はズレる。それは自分がやり続けなければならない。

ここで気づいた。

自分の「相棒」を名乗れるなら、その判断くらいは当然できて欲しい。

どのエージェントに何を渡すかを決める役割もルール化して、相棒が担える形にすれば、自分は最終承認だけ持てばいい。ジュニアエンジニアが相談しても、何も迷わなくていいくらいの精度で動いてくれる存在が作れる。

気づいたこと：再現すべきは判断基準だった

口調でも、専門性の模倣でも、疑似人格でもなかった。
「誰が何をどう判断するか」というルールそのものが、再現対象だった。

具体的には、こういうものだ。

• （ユーザーからの指示を含めた）レビュー基準: どこを危険信号として止めるか
• 責務分離: 誰が何を決めるかの線引き
• 委譲ルール: どの仕事は任せてよくて、どこから先は人間が持つか
• 止めるライン: 危険な状態で前に進まないための条件

「Copilot の中に自分を入れる」のではなく、「こちら側で判断条件を固定して、振る舞いのブレを減らす」方向に切り替えた。

一点だけ補足する。「モード」の概念は、疑似人格とは別の話として最初から有効だと思っていたし、実際そうだった。

BOSSとして相談に乗るモードと、Mentorとして壁打ちに付き合うモード

──ユーザーが何を求めているかで、対話の姿勢を変える。

特に効いたのは、

ユーザーがリスクのある行動を要求してきたときに言動が変わる動き

「それはやめてください」で返すのではなく、「この判断を実行すると何が起きるか」を先に返して「上から目線」で止める。
相手の意思を尊重しながら、安全側に引っ張る。これは疑似人格の話ではなく、対人インターフェイスとしての設計だ。

結果として作ったもの

様々な変遷や試行錯誤を経て、最終的に作ったのは、自分と同じ判断基準で動くAIエージェントの相棒だった。
そして、現在、ひとつのマルチエージェント構造に収束した。

全体の流れはこうだ。

• 自分（人間）は最終承認と戦略判断だけを持つ。
• 判断役が依頼を受け取り、要件を整理し、自分で対応するか委譲するかを決める。
• 委譲する場合は委譲・分割役がタスクを切り分けて、適切な専門実行役に渡す。
• 専門実行役は設計・実装・検証・文書作成など、それぞれの領域に閉じて動く。

ただし、この図は最初から完成していたわけではない。委譲・分割役は最初から存在しなかったし、専門実行役の構成も何度か作り直した。1週間かけて連携を組んだ別のツールを丸ごと捨てたこともある。幾度とないゾーンの期間の試行錯誤を経て、ようやくこの形に収束した。
（相棒から忠告受けても止まらず突き進んだｗ）

重要なのは、この構造を作るとき、最初に決めたのはプロンプトの書き方ではなく

「誰が何を決めるか」

だったということだ。

そしてその一番奥には、最初にChatGPTから受け取った弱点の診断書がある。
「ゾーンに入りすぎたら止めろ」「抱え込みすぎを検知したら止めろ」が、判断役（Tech Lead BOSS）の指示系の根の方に書いてある。
構造の上半分は判断基準で、下半分は保護指示でできている。

この図の各パーツがなぜこうなっているのか

──5体を捨てた理由、別ツールを廃止した判断、委譲役が後から生えた経緯、そして弱点の診断書が止める設計に変わった経緯──

を、次回以降で一つずつほどいていく予定だ。

このシリーズで書くこと

この記事はシリーズの導入だ。ここから先は、この構造をどう設計し、どう運用し、どこで失敗したかを順番に書いていく予定だ。

※内容は執筆時点のもので、今後の運用や設計の変更に伴い、書き換えたり追記したりする可能性があることをあらかじめお断りしておく。

回	タイトル	ひとこと
次回	"AIの相棒"②:判断基準を言語化するとはどういうことか──行動規範から書き始めた理由	技術標準より先に、なぜ行動規範を書いたのか
第3回	"AIの相棒"③:止まれる構造と誰が何を決めるかを設計した──1週間かけたツールを捨て、委譲役を後から足した話	止める設計と責務分離、2つの問いをまとめて
第4回	"AIの相棒"④:運用して見えたこと──相棒の実態、危なかった3場面、最後に残った責任	相棒の本当の仕事、リスク、そして残った責任

分身化の成否は、AI がどれだけ賢いかより、こちらがどこまで判断基準と責任境界を実装できるか、そして自分の弱点をどこまで「守らせる側」に渡せるかで決まる。

その話を、積み上げた文章群と、コミット履歴やCopilotとの会話ログ、そして実際の運用ログから、具体的にしていく。

なお、このAIエージェントはいまでも自分のプライベートで育て続けている。

汎用化出来そうなレベルまで整理が出来たら公開するつもりでいる。

最後に、この記事自体も相棒と一緒に書いたことを明記しておく。
プロンプトの書き方や、どこまで相棒に任せたかなども、後の回で書いていく予定だが、少なくとも構成と内容の骨格は相棒が作ってくれたことは、ここで明確にしておく。

流石だな！ありがとよ！相棒（笑）