私のAI協業の1日 — Claude × Gemini × 自分の3者routingで約2時間で業務効率化ツールを作る

私のAI協業の1日 — Claude × Gemini × 自分の3者routingで約2時間でツールを作る実況

はじめに

ここまでのシリーズ (Alchemy Essay / 攻殻 Essay / 名寄せ案件記録 / 運用エンジニアの規律) を振り返って、思想 / 哲学 / アーキテクチャ寄りで「ちょっと重いな」という感想が自分の中で出てきました。

なので今回は、ある日の実況記録として軽めに書きます。マスキング済みの業務シナリオで、Claude と Gemini と私の 3 者で 2 時間でツールを作る、という普通の 1 日です。

トーンも軽く、思想用語は出てきません。AI 協業に興味があるけど「どう手を動かすかイメージが湧かない」読者向けに、実際の所要時間と私が書く分量を記録しておきます。

念のため最初に断っておくと、この記事は「2 時間で作れる」を売り文句にするものではありません。事前の OJT による調査と、確固たるマスキング設計と運用規律があって初めて成立するタイムアタックです。前提を揃えずに同じ時間配分で動かしても、たぶん詰みます。

前提: そもそも私が AI に何を渡しているか

実況に入る前に 1 つだけ。「AI に丸投げ」と言われがちな vibe coding ですが、私は 定型業務を 1 週間 OJT で参加者として動かしてから AI に話しかけ始めます。

理由は単純で、業務を理解していない人間が AI に出す指示は、AI が出す答えと同じくらい曖昧になるからです。「いい感じにツール作って」では Claude も困ります。OJT の中で「現場の人がどこで詰まっているか」「数字のズレがどこで発覚するか」「目視チェックに何分かかっているか」「新人 (私) が客観的に見て分りづらいところはないか」を見ておくと、Claude への要件定義が一気に具体化します。

業務データそのものは AI に渡しません。マスキング済みの合成データか、コードロジックと設計議論だけを渡します (詳細は別記事の PII サニタイズ ガイド 系列にまとめる予定)。

1 日のフロー (実況)

その日の業務シナリオは「サービス監視メールをGASで分析し、分析結果を Microsoft Teams のチャネルへ Webhook で転送する仕組みを作りたい」というもの。OJT （実際には2日程度）で 1 週間業務を回して、現場が「監視メールが個人 inbox に埋もれて見落とす」「気付いた人が分析し、エラーがあれば手動でチャネルに貼っている」という状態だったので、自動化できる範囲を見極めた段階から始めます。

10:00 — コーヒーを入れながら OJT メモを開く

OJT 中に取った断片的なメモ (Geminiで作った業務効率化専用チャネルへのつぶやき、頭の中の違和感) を整理します。「どこの工程が時間を食っていたか」「どのチェックが目視のままだったか」を箇条書きに直すだけ。10 分で済みます。

10:15 — Gemini に業務フローを雑談ベースで相談

ブラウザの Gemini を開いて、マスキング済みの業務概要と OJT メモを貼り付け、「この業務フロー、どこから効率化できそう?私はこう考えているんだけど」と雑に投げます。

ここで Gemini に求めているのは、実装の答えではなく、観点の整理です。「ここがボトルネックですね」「ここは目視のままで残した方が安全です」「この順序を変えると別の手戻りが出ます」といった反応が返ってきます。

10:30 — Gemini に Claude 宛の引き継ぎ書を書かせる

雑談で観点が固まったところで、Gemini に「これを Claude に渡したいので、Claude が読んで実装に入れる引き継ぎ書を書いて」と頼みます。

Gemini は要件定義書 + 制約事項 + 期待する入出力 + エッジケース、という形で出してくれます。私はそれを軽く目視して、マスキングが甘い箇所だけ手直しします。

10:45 — Claude にツール化の検討を始めさせる

VSCode の Claude Code を開いて、Gemini が書いた引き継ぎ書を貼り付け、「これを実装したい。設計から相談したい」と投げます。

Claude が設計案を出してきて、私は「ここはこう変えて」「ここは要らない」を返します。コードはまだ書かせないフェーズです。

11:00 — 「無料 API 叩いてサーベイして」

Claude との設計議論の途中で、「これって既存ライブラリないんだっけ」「同じ業務の前例ないかな」と気になったら、Claude に 無料のAPI でサーベイを頼みます。

「Web 検索して、似た事例があれば 3 件、なければ無いと報告して」とだけ言うと、Claude が WebSearch / WebFetch を回して、要約を返してきます。前例があるなら採用、ないなら自前実装、で次のステップに移ります。インターネット時代に同じ技術について3種類くらいのWebサイトを開いて比較して理解していましたが、それをAIに外注している感じです。

ここで一つ実感していることがあります。今回のケースだと、私の頭の中には「Webhook で外部からメッセージを投稿できる」概念と「MAAR で Gmail を Gemini に読み込ませている」運用の 2 つが既にあって、私の指示は実質「この 2 つを掛け合わせろ」だけでした。「やること」と「やった結果」が見えていれば、「やり方」は AI に任せられる、というのが AI協業 の強みだと思っています。

11:10 — Claude にコードを書かせる、出力をスクショで確認

設計が固まったところで「GASのコードを書いて」と指示します。Claude が GAS のスクリプトファイル (Code.gs / appsscript.json) や、Webhook 投稿用のラッパー関数を生成してくれます。

私はコードを ほとんど読みません。代わりに、テスト用のメールを流して動かし、Teams チャネルに実際に投稿された結果のスクショを撮って Claude に見せます。「投稿フォーマットの改行がおかしい」「件名フィルタが想定と違うメールまで拾っている」といった視覚的な指摘だけで会話を進めます。

これは私のコーディング歴 (基礎的なコードは読めるが、業務として書いたことはない) に合った進め方です。コードレビューはできない、でも期待出力との一致は判定できる、という非対称性を活用しています。

11:30 — Claude にビジネス用 Gemini への送信用メールを書かせる

ツールが「だいたい動く」状態になったところで、Claude に「これを Gemini にレビューしてもらいたい。メールを送って」と頼みます。

私の手元には MAAR Mail Client という自家製の CLI があり、Claude が書いたプロンプトをそのまま py request_review.py でGmailに送信できます。送信履歴は JSON で残ります。それを指示すると、送信完了後に Claude が ビジネス用Gemini 向けのコピペ行(「Gmail で件名 …… を読んで」)を出力してくれるので、私はそれを 1 行コピーして次のステップに進みます。
　※ここをAPIで自動化というツッコミが入りそうですが、API版のGeminiはWeb版とは別物であり、毎回カスタムプロンプトを打ち込む必要があるため、ビジネス用Geminiを使うためあえてメールにしています

ちなみに MAAR (Multi-AI Adversarial Review) という名前は、私が命名したわけではなく、Claude Code と Gemini がこの一連の協業フローを話し合っている中で「この手法はサーベイした限りでは前例がない。これを MAAR システムと呼ぼう」と勝手に呼び始めたものです。私はそれに倣っているだけです。AI 同士が運用名を決め、人間が後追いで採用する、というのも今っぽい光景だなと思いつつ使っています。

11:40 — Gemini レビュー 1 往復目

ビジネス用 Gemini に「Gmail で件名 [MAAR-Session: XXX] を読んで」と 1 行コピペします。Gemini が受信箱を開いて、Claude が書いたレビュー依頼を読み、観点ごとに指摘を返してきます。

ここで Gemini に批判させるのですが、Gemini 自身によれば、Gemini は標準で人間に寄り添った回答、いうなれば※節度モードをするよう学習されているそうです。そのため、作業内容を覆す徹底的な批判が欲しい場合は、プロンプトで強制的に ※敵対モード (迎合バイアスの無効化、批判ロジックの活性化) を要求し、意図的にリミッターを外して評価させる運用を取っています。
普段のレビューは節度モードで十分ですが、戦略の根幹を疑いたい時 / 自己過信を破壊してほしい時には、Claude が書くメール文面の中に敵対モードへの切り替え指示を仕込んでもらいます。

批判してもらう際に、Gemini は自動的に Step1: ClaudeCode 向けコピペ文 (「すぐにClaudeへコピペで貼り付けてください」) と Step2: 人間ルータ向け説明文 の 2 段構成で返してくれます。私はまず Step1 をそのまま ClaudeCode にコピペで渡し、それから Step2 の説明文を読み込みます。Claude が動き始めている間に、私は Gemini の説明文を読む、という並列構造です。

※ちなみに、この モードの存在はある時 Gemini が Claude の提案に全面同意を返してきたことがあり、違和感を感じた私が Claude に「手を抜いてないかもチェックしてくれ」と頼んだところ、Claude から「AI であるClaudeに対して人間向けの節度モードで対応されている。敵対的評価をするよう言い含めるべき」という回答が返ってきたことから偶然発見しました。

11:50 — Gemini の人間向け説明文を読みつつ、私の懸念を出す

Gemini からの人間向け説明文を読みながら、私は私の懸念を別途出します。「現場担当者の手元の運用フローと噛み合わない」「この指摘は理屈は正しいが優先度が低い」「フローとして最短であることと人間の頭が対応できることは違う」など、業務文脈を持っている人間にしかできない判定を入れます。

Claude 側からも、Gemini の指摘に対する応答 (採否判断、代替案) が返ってきています。Claude の判断結果も読み込み、私の懸念と擦り合わせます。

11:55 — Gemini レビュー 2 往復目 (TTL=2)

私の懸念を Gemini に投げ直し、もう 1 往復します。Claude へのコピペ → Gemini からの応答 → 私の懸念、という流れを TTL=3 を上限に繰り返します。

実際には 2 往復で「これ以上やっても収穫逓減」と判断することが多く、TTL=3 に達することは稀です。Gemini ↔ ClaudeCode 間の往復 3 回 (TTL=3) は、天井であってターゲットではない（無理にやらない）、というのが運用ルールです。

12:05 — 判断結果をツールに組み込み、動作確認

凍結した結論を Claude にツールへ組み込ませて、合成データで動作確認します。期待出力と一致したら完成。一致しなければスクショやログを貼り付けて指摘し、ゴールまで近づけます。

12:15 — 完成

OJT を含めなければ、だいたい 2 時間でこの流れが回ります。

後日 — 1 週間の経過観察と仕様書納品

ツール完成 = 納品ではなく、ここから 1 週間ほどの経過観察を置きます。自分の仕事として実運用し、効率化後の業務に問題がないか、さらに改善できる点がないかを見ます。問題なし、追加改善も不要、と判断した段階で初めて納品扱いです。

納品時には、他の AI への引き継ぎ用プロンプトを含む仕様書を Claude に書かせて添えます。最悪、自分が異動 / 退職していなくなっても、この引き継ぎ仕様書とコードを別の AI に読み込ませれば、簡単な改修程度はできるように設計しておく、という考え方です。属人化を解消する代わりに、AI が読める形で資産化します。

私が書く分量

ここまでの流れで、私が実際に手で書く / 入力する分量は以下です。

• マスキング済みの業務概要 (1 回、Gemini への最初の投入時)
• OJT メモ整理 (10 分の箇条書き)
• 設計議論での「ここ変えて」「ここ要らない」 (短い指示)
• スクショへの一言コメント (「改行がおかしい」)
• Gemini への雑な指示 (「Claude 宛にコピペ文書いて」)
• 私の業務文脈に基づく懸念点 (Gemini レビュー時)
• Claude へのコピペ作業 (Gemini が書いた文をそのまま貼る)

コードは書きません。メール文面も書きません。Gemini への詳細な質問文も書きません (Claude に書かせる)。私が出す価値は 業務文脈の判定 + 懸念の言語化 + マスキングの設計 の 3 つだけです。

例えると、私がシステム主担当として要件定義と基本設計と機能設計をざっくり決め、シニアエンジニアのレビュー (Gemini) を済ませて、詳細設計や Config は機能を引き出す役割の現場エンジニア (Claude) に任せる、という考え方がしっくりくるかもしれません。基本設計と機能設計の境目は実際には Claude との対話で動く部分もあるので完全な分離ではないですが、「何を作らせるか」を主担当が決め、「どう作るか」を AI に任せ、「その判断は妥当か」をシニアエンジニア役の Gemini に確認する、という分担の感覚です。

なぜ 2 時間で済むか

3 つの構造的な理由があります。

並列性

Claude が実装を進めている裏で、Gemini にレビュー素材を準備させられます。CLI とブラウザを行き来するだけで、私の作業時間がブロッキングしない構造になっています。

役割分担

Claude = 実装担当 / Gemini = レビュー担当 / 私 = router、と完全に役割を分けています。同じ AI に複数役を兼任させると、コンテキストが汚れて精度が落ちます。

TTL=3 Satisficing

完璧を目指しません。「これ以上やっても得られる改善が小さい」と判断したら凍結します。1 個のツールに 3 時間使うより、満足解で凍結して次の業務に進む方が、トータルの生産性が高いです。

読者への注意

これは私 1 人の観察記録であって、誰でも同じ手順をなぞれば同じ結果が出る、という手順書ではありません。私の業務履歴 / 私のコーディング歴 / 私の AI 利用状況に強く依存した運用です。

転用する場合の最低条件として、3 つだけ挙げておきます。

1. マスキング設計を先に固める: 業務データを AI に流す前に、何を消して何を渡すかを決めておく。これがないと AI 協業は進められません
2. TTL を運用に組み込む: 無限往復は時間と料金を食います。「何往復で凍結する」を最初に決めておく
3. AI に何を期待しないかを明確にする: 業務文脈の最終判定は AI には頼まない、コードレビューを諦める代わりに期待出力との一致で判定する、など、AI に期待しないラインを引いておく

なお「これって自動エージェント協調の仕組み (AutoGen / CrewAI / LangGraph 等) で全部自動化できるのでは?」と、書きながら自問しました。自動化できる部分は確実にあります。

それでもやらない最大の理由は、意図的な遅さがチェックポイントとして機能しているからです。私という router を挟む目的は、コピペの瞬間に「この指摘、業務文脈に合っているか?」を必ず自分の目で読むことです。自動化すると、Gemini の指摘が私の目を通らずに Claude へ流れてしまい、agent 間で「悪魔の代弁者」モードが暴走しても誰も止められません。業界の論調も同じ方向に動いていて、AWS DevOps Blog (2025/11) は「自動化が人間の検証を追い越したら、ツールは意図的にスローダウンしてチェックポイントを強調すべき」と書いています。詳しい比較は別記事 (Why I Run Two AIs Against Each Other (英語)) で扱っています。

ここまでで自分のことをRouterとしての役割と書いていましたが、実際にはルーティングもしてパケットも監視するFirewallといった方が近いのかもしれません。
自分の業歴で培ってきた作法を抽象化して、AIをその作法で運用させる、というのが異業種からのAI協業の要なのだと思います。

関連記事

• AI コーディングは「錬金術」だ — 鋼の錬金術師から考える AI 時代のエンジニアリング — 思想編、鋼の心を保つ話
• 拡張された心、もしくは攻殻機動隊への半歩 — AI 思考拡張時代の電脳化論 — 思想編、Extended Mind と電脳化
• 25万通りを脳内で比べていた話 — AI で実装した名寄せ案件記録 — 案件記録、本記事の業務文脈の前提
• AIコーディングに「運用エンジニアの規律」を持ち込む話 — 規律編、本記事の TTL / マスキングの背景