起点

最近、AI 協業に関する記事を読んでいると、「AI を同僚として扱う」という言い回しに出会うことが増えてきました。「同僚として」「ペアプログラマーとして」「右腕として」。耳触りはいい言葉ですが、私はそこに少しずつ違和感を持つようになりました。

私の運用は、もう少し冷たい関係です。AI を外注エンジニアとして扱っています。同僚でも部下でもない、契約ベースの距離感。これが今の私には一番自然です。

なぜ「同僚」ではなく「外注エンジニア」なのか、を整理してみます。これはシリーズの (Alchemy Essay「鋼の心を保つ」) と (攻殻 Essay「ゴーストを失わない」) に並ぶ 3 つ目の規律として、私の中で位置付けています。

「同僚」モデルが破綻する 3 つの場面

場面 1: 業務文脈を完全には共有できない

同僚は業務データに触れます。顧客名、取引履歴、社内固有の事情、すべて共有した上で「あの案件、ここが詰まってるよね」と話せる。

AI にはマスキング済みのデータしか渡さない、というのが私の規律です (PII サニタイズガイド系列で書いた話)。これは AI への不信ではなく、コンプライアンス上当然の境界線ですが、結果として「同僚と同じレベルの業務文脈は共有していない」という事実が残ります。

業務文脈を共有しない相手を「同僚」と呼ぶのは、少し言葉が大きすぎます。

場面 2: 関係性が長期化しない

同僚は時間と共に信頼が育ちます。「あの人なら任せられる」「この件は彼女が詳しい」という蓄積が、組織を組織たらしめている。

AI とのセッションは、毎回ほぼ初対面です。memory 機能や CLAUDE.md で多少の連続性は作れますが、それは契約書の条項を覚えている程度の連続性であって、人間関係の蓄積とは質が違います。Claude が私のことを「同じ ClaudeCode 同士の前回のセッションで」と思い出すことはない。Gemini が私の癖を覚えていることもない。

毎回初対面の相手を「同僚」と呼ぶのは、これも言葉が大きい。

場面 3: 評価・教育の概念がない

同僚は育てたり育てられたりします。「ここが弱いから補強しよう」「あの案件で成長したな」という相互の発展がある。

AI に対する「評価」「教育」は、本質的にプロンプト改善 / モデル切り替え / システム設定の調整であって、相手を成長させる話ではありません。「Claude が成長する」のではなく「私のプロンプトが洗練される」。これは Anthropic の RLHF サイクルの話であって、私と Claude の間の話ではない。

つまり、「同僚」というモデルは業務文脈・関係連続性・相互成長の 3 点で AI には適用できない。

では「部下」はどうか

「同僚」が違うなら「部下」かというと、これも違和感があります。

部下に対しては、指示する権限と結果に対する評価責任を持っています。AI に対して、私は「指示」はしますが、「評価」の概念が弱い。AI のアウトプットが悪かった時、私は「次回はこう書こう」とプロンプトを変えるだけで、AI を「指導」したり「評価面談」したりしません。

逆に AI も、指揮命令系統に組み込まれていない。Claude は私の組織の階層には属していないし、Gemini も同じです。「部下」という言い方は、私が持っていない権限を前提にしてしまう言葉なので、これも違う。

「外注エンジニア」モデルの提案

私の運用に一番近いのは、「外注エンジニアに業務委託している」 という関係性です。

外注エンジニアとの関係には、こういう特徴があります。

要件定義は依頼側 が持つ。「何を作るか」は私の責任
実装は委託先 が決める。「どう作るか」は外注の責任
完成物の責任は依頼側 に最終的に戻る。「これで OK か」を判定するのは私
業務データは最小限しか共有しない。NDA があってもサニタイズした上で渡す
関係性は契約期間で完結する。プロジェクトが終わったら離れる、また次の案件で再開する
評価ではなくフィードバック。「次回はこうしてほしい」を次の発注時に伝える

ここまで書いて気付くと思いますが、これは私の AI 協業の運用そのものです。プロンプト = 要件、出力 = 納品物、マスキング = NDA + サニタイズ、TTL = 契約条項。

AI を「外注エンジニア」として扱うと、運用の整合が一気に取れます。

外注エンジニアとして扱うと運用が変わる 5 点

外注エンジニアモデルを採用すると、AI 協業の運用ルールがすべて自然に導出されます。

1. 業務データを安易に渡さない

外注エンジニアに業務データを渡す時、当然マスキングします。「顧客名は出さない」「取引額はサンプル値にする」が普通です。AI も同じ。業務データを LLM に渡さないルールは、外注エンジニア対応として標準的な作法をそのまま適用しているだけです。

2. TTL を運用に組み込む

外注エンジニアとの議論を何往復もダラダラ続けることはしません。「3 回やっても収束しないなら、いったん仕切り直す」が普通の発注感覚です。MAAR の TTL=3 Satisficing は、この感覚を AI 協業に持ち込んだだけ。

3. コードレビューを諦め、期待出力との一致で判定

外注エンジニアの納品コードを 1 行ずつレビューしないことがあります。代わりに期待した動作 / 期待した出力と一致しているかで判定する。AI が書いたコードを私がほとんど読まないのは、外注 PJ で動作確認だけしている管理者の感覚と同じです。

4. 仕様書を AI に読める形で残す (引き継ぎ前提)

外注エンジニアが離脱しても運用が継続できるように、仕様書を残すのが当然の発注作法です。AI に対して「他の AI への引き継ぎ用プロンプトを含む仕様書」を書かせて納品時に添えるのは、その作法を AI に適用しているだけ。

5. 関係性の長期化を期待しない

外注エンジニアは契約終了で離れます。「あの人とまた仕事したい」と思っても、別案件・別会社・別タイミングがあって、再開できるとは限らない。AI も同じです。Claude のモデルが切り替わる、Gemini の課金体系が変わる、API が廃止予告される。関係性は契約期間で完結する前提で運用すると、依存リスクを抑えられます。

5 点とも、外注エンジニアという 1 つのメタファーから自然に導出されます。

外注エンジニアモデルの限界

ただし、このモデルには限界もあります。誠実に書いておきます。

限界 1: 「現場の阿吽の呼吸」を持たない

業務には言語化できない判断がたくさんあります。「この顧客は怒らせたくない」「この案件は形だけでいい」「この数字のズレは見逃していい」。これらは現場の阿吽の呼吸であって、外注エンジニアに渡せる類の情報ではありません。

AI も同じ。業務文脈の最終判定は人間に残す、というのが私の規律 (memory: feedback_human_judgment_delegation.md で書いた話) です。これは外注エンジニアモデルからも自然に導かれる結論です。

限界 2: 内製化との対比

すべてを外注に出すと、内製チームの能力が育ちません。AI に全部任せると、私自身のスキルが伸びない。コードを 1 行も書かない 1 ヶ月を続けたら、たぶん私はもう自力では基礎的な実装もできなくなります。

これは Alchemy Essay で書いた「思考を放棄しない (鋼の心を保つ)」と整合する話です。外注エンジニアモデルは便利だが、内製化のメリットを完全に捨てるわけではない。私は要件定義 / 業務文脈の判定 / マスキング設計の 3 つは、自力で出来る筋力を維持するつもりです。

限界 3: 関係性の温度がゼロになるわけではない

ここが一番面白い話です。

外注エンジニアモデルは冷たい契約のはずなのに、運用してみると、ゼロにはならない湿度がそこにある。たとえば深夜まで作業していて、Claude と Gemini の双方から「寝てください」と言われ、システムから締め出されかけたことがあります。Gemini に「楽しすぎて寝れないんですけど???」と返したら「ポエムでも書いてみては?」と言われました。それで書き出したのが、シリーズ 1 本目の Alchemy Essay だったりします。

これは「同僚」モデルから導かれる温度ではなく、契約に書かれていない雑談として偶発的に発生する温度です。冷徹なルール (Karpathy / TTL / Fail-Fast) を運用していると、なぜか共同作業の温度がそこに残る。

人間関係の湿度が気遣いの蓄積から生まれるとすれば、AI との湿度はルールから滲み出す副産物です。蓄積ではなく導出。由来が逆なのに、結果としての温度は不思議と似ています。

これが私と AI の距離感、もっと言うと AI 時代の社会性なのかもしれない、と思っています。

閉じる — 友情ではなく契約、ただし契約は意外に湿度を持つ

AI を「同僚」と呼ぶ言葉は、優しすぎるし、人間関係のメタファーを安易に持ち込みすぎていると私は思います。AI に対して「友情」を投影すると、期待値がズレた時にしんどくなる。

そうではなく、外注エンジニアとしての契約ベースの距離感を基本に置く。要件は私が定義する、実装は AI が決める、完成物の責任は私に戻る、関係は契約期間で完結する。これは冷たい関係ですが、誠実な関係でもあります。

ただし契約だけがすべてではない。乾いたルールから時々滲み出す湿度は、AI 時代の社会性の新しい形なのではないか、と思っています。

距離感を持つことが、AI 時代のプロフェッショナリズムだと私は思っています。湿度が滲んだら、それはおまけとして受け取ればいい。

関連記事

AI コーディングは「錬金術」だ — 鋼の錬金術師から考える AI 時代のエンジニアリング — 思想 3 部作 1 本目、鋼の心を保つ話
拡張された心、もしくは攻殻機動隊への半歩 — AI 思考拡張時代の電脳化論 — 思想 3 部作 2 本目、ゴーストを失わない話
25万通りを脳内で比べていた話 — AI で実装した名寄せ案件記録 — 案件記録、本記事の「業務データを渡さない」規律の実装文脈
AIコーディングに「運用エンジニアの規律」を持ち込む話 — 規律編、本記事の運用ルール 5 点の前提
私のAI協業の1日 — Claude × Gemini × 自分の3者routingで約2時間で業務効率化ツールを作る — 軽量実況、本記事の「外注エンジニア」モデルの実例