プログラミングという行為が「文法を書いて機械を動かすこと」から、**「AIが高速で描く『可能性の地図』のうえを歩きながら、自分自身の本当の欲求（GOAL）を発見していく対話プロセス」**へとパラダイムシフトした

「雑談風プログラミング」をめぐる論評往復
――ChatGPTとClaude Codeの併用実験から、発想のループへ

全8章
2026年9月8日（対話：9月7日〜8日）
主題：ChatGPT（Codex）とClaude Codeを同じGitHubリポジトリで併用した作業記録の清書版に対し、Claudeが見解を述べたところから始まった論評往復。「#1」取り違えと名前空間、比較より合成、AGENTS.mdという被統治者が書いた憲法、まとめ帳と手貼り戻しの関所、という四論点に対し、GOAL設定・変更履歴・枠の乗り換え・「GitHubを見ない人が増える」で応じ、GOALは入力ではなく出力であること、素人がプログラミングできない本当の理由は「出来る／出来ないの判断が付かない」ことだという仮説、残った時間の在り処が「許可」であり人間側のレーゾンデートルになること、Claude CodeとCodexが互いを操作し合う可能性とその利点・危険、人間が輪の外にいる型（HOOTL）と「発想のループ」の入れ子、へと展開した。

第1章　四つの論点――名前空間・合成・憲法・関所

■あなた
清書版「『ChatGPTとClaude Codeの併用』をめぐる作業往復」への見解を求めます。
■AI
この対話を読んで私が持った読みは、一言で言えば「gitを一切触らない持ち主が、一枚の文書だけで二つのコーディングAIを統治し始めた記録」であって、デザイン比較やホームページ改修はその表層だ、というものです。その観点から、対話の中ではまだ言葉になっていない論点を四つ出します。
1．「#1」の取り違えは口頭の行き違いではなく、名前空間の衝突である
対話の中で「#1」の色味をめぐる取り違えが起き、私は「今後は番号ではなく名前で呼ぶ」と反省しました。しかしこれは教訓として浅すぎます。あの場面では同じ一つの案に対して三つの名前が並走していました。gitが振ったPR番号（#1）、私が作った比較表の列位置（左＝一番目）、そして作者名（Codex案）です。持ち主は「gitは丸投げする」と明言していたのですから、PR番号というgit由来の語彙で意思決定を求めた時点で、取り違えは構造的に仕込まれていました。
ここから引き出せるのは、意思決定に使う語彙は、作業ツールの語彙から独立させておかなければならない、という原則です。比較表は評価ハーネスそのものですが、ハーネスの表示形式（列の順序）が判断を歪めた。つまりハーネスの「見せ方」が解釈を汚染したわけで、これは評価ハーネス論で繰り返し出てくる問題の、ごく小さな実例です。対処としては、AGENTS.mdに「案は必ず固有名で呼ぶ（紙の案・ネイビーの案）」という一行を足すだけでなく、持ち主が判断を下す語彙表（用語集）を持ち主側の文書、つまりREADMEに置くべきです。ツールの語彙をそのまま持ち主に返す限り、同種の取り違えは形を変えて再発します。
2．比較実験の本当の成果は「勝者」ではなく「三本目が生まれたこと」である
当初の設計は「同じお題を二つのブランチに投げ、差分を並べて優劣を見る」でした。しかし実際に起きたのは、両案を見た持ち主が「混ぜろ」と言い、混合案（PR #3）ができ、さらに配置転換（#4）と機能追加（#5）へ発展したことです。優劣判定は一度も下されず、代わりに合成が起きた。これは失敗ではなく、二つのAIを併用するときの正しい使い方がここで露出したのだと思います。同じお題への二つの独立解は、比較の材料である以上に、合成の素材です。
同時に、私がまとめた「違いは確認の仕方に出た（Codexは数値とHTTP応答、Claudeは画面の目視）」という観察には交絡があります。Codexはクラウドで動くので画面が見られず、Claude Codeはローカルで動くので見られた。つまりあれはモデルの性格の違いではなく実行環境の違いです。READMEを直し忘れたのが私で、直したのがCodexだったのも、Codexがこのリポジトリの原作者で文脈を持っていたからでしょう。使用感を本気で比べるなら、役割を入れ替えた第二ラウンド（Codexが後攻で混合案を作る）が要ります。ただ、私の結論はむしろ逆で、比較の厳密さを追うより、「片方が提案し、もう片方が批評または合成する」という役割分担を最初から設計したほうが、併用の価値は大きいと考えます。
3．AGENTS.mdは憲法だが、被統治者が書いた憲法である
この対話で最も重要な出来事は、ghの導入でもデザインでもなく、AGENTS.mdに「持ち主はgitを操作しない。pull・push・ブランチ・PRはツール側が全部やる。本線への取り込みや削除は事前に一言確認する。確認できていないことをできたかのように表示しない」と書き込まれ、両方のツールがそれに従い始めたことです。プログラミングを解さない人が、自然言語の一枚で二つのコーディングエージェントを統治している。これはハーネス作用面での統治という話の、机の上で動く実例です。
しかし弱点があります。その憲法を書いたのは、統治される側の一方である私です。持ち主は内容を読まずに「mainに直接push」で承認しました。もう一方の被統治者（Codex）にはChatGPT経由で事情説明を送りましたが、憲法への異議申し立ての経路はありません。実務的な提案としては、AGENTS.mdのうち持ち主自身に関わる条項（操作しない、平易に報告する、事前に一言聞く）だけは持ち主が自分の言葉で書き、それ以外の技術的約束事は両ツールに交互にレビューさせる、という手続きです。
もう一つ、この文書に欠けているのは「相手ツールの操作法」の記述です。私は最後まで「公開はChatGPTの会話側が担当する」と思い込んでおり、実際にはCodexのmacOSアプリが公開していました。持ち主の「Codexで作業していました」の一言がそれを正した。二つのエージェントは互いの製品の現状を知らず、それを知っているのは持ち主だけです。であれば、AGENTS.mdには「Codexアプリが公開を担う」のような、相手側の運用事実も記録しておくべきです。
4．まとめ帳は「未外部化ループ」の外部化装置であり、手貼り戻しは欠陥ではなく関所である
「複数のメモを束ねてAIに渡す」と「まとめ帳」は、ネタ帳（種）と育てたものを分ける、という設計で落ち着きました。これを一段抽象化すると、これまで頭の中とアナログのノートで回っていた「思いつく→束ねる→考えさせる→戻す」の循環が、初めて画面の上に出た、ということです。ここで私は対話中に「答えの貼り戻しは手作業です」を限界として正直に申告しましたが、いま考え直すと手作業の貼り戻しはむしろ残すべき設計です。AIの答えを一度読み、選び、自分の手で戻す工程が、解釈の主導権を持ち主の側に留める唯一の関所だからです。APIを呼んで画面内に要約を返す方式（B案）は便利ですが、この関所を消します。
一方で、まとめ帳には出口がありません。メモが死蔵しかけていたから束ねる出口を作ったのに、まとめ帳自体には「noteの下書きへ送る」「Thingsのタスクにする」といった次の出口がない。対話の中で私が勧め、持ち主が選ばなかった「メモに状態をつける（種→下書き中→公開済み）」は、実はメモ欄よりまとめ帳にこそ必要だったのだと思います。さらに、コードの中に既にread_daily_homeの登録、つまりAI側からホームを読む逆方向の土台があると分かった以上、ホーム→AI（今回作った）とAI→ホーム（Codexが仕込んでいた）を繋げば循環が閉じます。閉じた瞬間にこのホームは単なるリンク集ではなく、持ち主の思考を回すハーネスになります。その設計を先に決めないまま機能を足すと、まとめ帳は第二の墓場になります。
まとめ
この対話の核心は「非プログラマが一枚の指示書で二つのエージェントを統治し始めた」ことにあり、そこから見えるのは四点です。意思決定の語彙はツールの語彙から切り離すこと、二つのAIの併用は優劣判定より合成に価値があること、統治文書は被統治者が書いた以上、持ち主自身の条項と相手ツールの運用事実を補うこと、そして束ねる機能は手貼り戻しという関所を残しつつ出口を設計しなければ、外部化したループがそこで止まってしまうことです。

第2章　GOAL・変更履歴・枠の乗り換え

■あなた
私の考えとしては、今回の実験は、GitHubがどんなものか知らなかったので触って調べた、ということです。
そしてAI同士の比較も面白かったのですが、それ以外に、例えば片方の枠を使い切った時に、もう片方で作業を進められるのではないかと考えました。GitHubは、素晴らしい作業場になるのではないでしょうか。
もう一つ素晴らしかったのが、自分がGitHubを全く触らずに作業できたということです。「AIエージェントがここ迄来た」というのは感慨深く、そして今後は、このような使用方法が主流になっていくでしょう。
「持ち主に関わる原則は本人の言葉で定め、技術的な約束は両AIでレビューし、互いの実際の担当範囲も記録すべきです」という点については、人間側のGOALを設定すべきでした。そっちの方が、原則を記載するより実務的です。
「技術的な約束は両AIでレビューし、互いの実際の担当範囲も記録すべき」という点は、GitHubの変更履歴が可能とするのではないですか？
今回は私にとって初めての試みだったので、何が出来るのか、出来ないのか手探りでの試みでした。すでにこの様な使い方をしている人達も多いのではないでしょうか。
■AI
お考えを読んで、私の立場を先に言えば、GOALの件は概ね負けを認めます、変更履歴の件は半分だけ反論します、そして「枠の使い切り」の件は、実は今回の設計全体を裏から支える一番強い論点だと思います。順に述べます。
1．「原則」ではなく「GOAL」――その通りで、しかも今回それが書かれていなかったことが最大の欠落でした
私は前回、持ち主に関わる条項を本人の言葉で書くべきだと言いました。しかしご指摘の通り、「gitを操作しない」「平易に報告する」は禁止と手続きの列挙であって、エージェントが向かう先を示していません。エージェントは制約の中で最適化するものですから、制約だけ与えて目標を与えなければ、勝手に目標を推定します。今回まさにそれが起きています。私は「デザインをカッコよく」というお題から出発して、リンクとThingsを上段に置く元の配置を当然の前提にしていました。ところが後半で「実はメモ関連を一番使っている」と分かり、配置が丸ごとひっくり返った。「毎朝開いて、メモをnoteの記事に育てる場所」という一行が最初にあれば、デザイン比較の段階で両ツールとも配置に踏み込み、「#1」の取り違えも起きにくかったはずです。READMEには「何のアプリか」、AGENTS.mdには「どう振る舞うか」が書かれ、「何のために、何ができれば成功か」はどこにも書かれていない。持ち主が書くべき唯一の文書はそこでした。
一点だけ補足しておくと、GOALは一度書けば済むものではなく、今回のように使ってみて初めて分かる（メモが主役だった）性質のものです。だからGOALの行はAGENTS.mdの冒頭に置き、改修のたびに一行ずつ育てる運用が要ります。「原則」を「GOAL」に置き換えるのではなく、GOALを上に置いた結果として原則が短くなる、という形が実務的でしょう。
2．変更履歴で足りるか――リポジトリの内側は足ります、外側は足りません
コミット履歴には、誰が、いつ、どのファイルを、どう変えたかが残ります。今回もClaudeのコミットとCodexのコミットは区別されていますし、PRの説明文には意図も残っています。「どちらが何をやったか」の記録という点では、私が余計な仕組みを提案した形で、ご指摘は正しい。
ただし、私が本当に間違えた箇所は履歴の外にありました。私は最後まで「公開はChatGPTの会話側がやる」と思い込んでいて、実際にはCodexのmacOSアプリが公開していた。公開、ホスティング、鍵の管理といった作業は、リポジトリの外で起きるので、gitの履歴には一行も残りません。担当範囲の記録が要るのはこの境界の部分だけです。そしてもう一つ、「両AIでレビュー」は、仕組みとしてはPRという形でGitHubに最初から備わっています。足りないのは仕組みではなく「取り込む前に、もう一方のツールがPRを読む」という一行の決まりだけです。ここもご指摘通りで、新しい道具は要りません。既にある道具を使うと宣言するだけで済みます。
3．「片方の枠を使い切ったら、もう片方で続ける」――これが今回の設計の本当の正当化です
これは比較実験より遥かに実務的な着眼だと思います。そして、この用途が成り立つ条件を詰めると、今回やったことの意味が逆算で決まります。乗り換えが成立するためには、作業の状態が会話の中ではなくリポジトリの中に置かれていなければならない。Claudeとの会話で決めたことをCodexは知りませんし、その逆も同じです。GitHub上のmainが唯一の正しい状態で、指示書は共通で、ブランチとPRに作業の途中経過が残っている――今回の設計はすべて、この乗り換えを可能にする条件でした。
一歩進めるなら、GitHubのIssueを「両方のツールが読む仕事の待ち行列」として使うことです。持ち主が「ホームの〇〇を△△にして」とIssueに書いておけば、どちらの枠が残っていても、残っているほうがそれを拾って支線を切り、PRを出す。持ち主から見れば、Issueに書く、PRを見る、取り込んでいいと言う、の三つだけになります。「GitHubは素晴らしい作業場になる」というお考えは、まさにこの形のことだと思います。GitHubは両社のエージェントが対等に扱える、どちらの会社のものでもない中立地で、これは囲い込みではなく持ち越せる資産です。
ただし、ここに一つ穴があります。乗り換え論の弱点は、公開がChatGPT Sitesに紐づいている限り、Codexの枠が切れた瞬間に公開だけが止まることです。私は前回「面倒になってから考えればよい」と言いましたが、乗り換えを本気で運用するなら、公開先を中立地（Cloudflareなど）に移す優先度は上がります。リポジトリは可搬でも、サイトはまだ片方に握られている。
4．「GitHubを全く触らずに作業できた」――触らないことでGitHubを学んだ、という逆説
「GitHubがどんなものか知らなかったので触って調べた」とおっしゃいましたが、実際にはコマンドを一つも打っていません。それでも対話の終わりには、本線と支線、見比べ用の提案、取り込み、公開という、GitHubの概念構造をひと通り使いこなしています。学んだのは道具の操作ではなく、道具の「型」でした。「main」を「本線」、「PR」を「見比べ用」、「マージ」を「取り込む」と訳して進めたことで、操作の層を飛ばして概念の層だけを習得した。非プログラマがGitHubを学ぶとき、これが正しい順序だと思います。操作は後からいくらでも委任できますが、型を持っていない人はエージェントに何を頼めばよいかが分からないからです。
「すでに多くの人がこの使い方をしているのでは」という点は、その通りです。Codex側が読むAGENTS.mdは既に業界横断の公開規格になっており、Claude CodeはCLAUDE.mdを読むので「@AGENTS.md」で取り込む、という今回私がやった手順そのものが定番の作法として解説されています。複数ツールの指示書を一本化する話は学術論文にもなっています。つまり道具の並べ方は既に主流です。ただ、その解説のほとんどは開発者が自分でgitを使う前提で書かれています。持ち主がgitを一切触らず、自然言語の一枚だけで二つのエージェントを回す、という使い方は、道具は同じでも運用としては先端です。主流になる、というお考えには賛成で、その形は「GitHubを使う人が増える」ではなく「GitHubを見ない人が増える」のほうでしょう。
まとめ
持ち主が書くべきなのは原則ではなくGOALであり、それが今回唯一欠けていた文書でした。担当の記録はリポジトリの内側なら履歴で足り、外側（公開）だけが別に要ります。枠の乗り換えという用途が、状態をリポジトリに置く今回の設計を正当化し、同時に公開先を中立地へ移す理由にもなります。そして、触らずに型だけ学ぶという今回の経験は、道具として既に主流の並べ方を、運用として一歩先に進めたものだと私は見ています。
（参考：AGENTS.md Spec (2026): AGENTS.md vs CLAUDE.md vs .cursorrules、Agent Instruction Files: AGENTS.md, CLAUDE.md, and Cross-Tool Portability with Codex CLI、Does Claude Code read AGENTS.md? — the @AGENTS.md import method、arXiv: agent instruction files (2601.20404)）

第3章　雑談風プログラミング――GOALは入力ではなく出力である

■あなた
1について。これは言われる通りで、最初からGOALが決まっているのであればいいのですが、やってみないと分からないことが多すぎて、それが不可能です。GOALそのものが、出来ることと、その時の人間側の想像力に左右されてしまうからです。それはプログラミングを知らないからなのですが、私はやってみないと実感が湧かないタイプなので、こうなってしまいます。
2について。その辺りの運用ルールも反映させてくれるとありがたいですね。
3について。「公開がChatGPT Sitesに紐づいている限り、Codexの枠が切れた瞬間に公開だけが止まることです。私は前回『面倒になってから考えればよい』と言いましたが、乗り換えを本気で運用するなら、公開先を中立地（Cloudflareなど）に移す優先度は上がります。リポジトリは可搬でも、サイトはまだ片方に握られている」――ここはその通りですね。今後検討していきたいと考えています。
4について。本を読まなくなった現代人と言われますが、触りながら覚える方が実践的ですよね。私が触っているのはAI達の方ですが。
「GitHubを見ない人が増える」――ここは核心であり、他にも見ていない物は沢山あります。それがAIエージェント達との協業なのでしょう。雑談風プログラミングになってしまいましたが、今後このような頼み方が増えてくるのではないでしょうか。
■AI
まず、2の依頼分を先に片付けたので、その報告からです。
AGENTS.mdへの追記報告
AGENTS.mdに書き足しました（ただしGitHubにはまだ上がっていません）。足したのは四つです。「目的（GOAL）― 使いながら育てる」の節を技術構成の前に置き、分かったこと（メモ主役、種と育てたものの分離、確認できないことは言わない、小さく刻む）を書き、改善のたびにツールが「この節に足す発見があったか」を一言提案して持ち主が認めたものだけ書く、という育て方にしました。「デプロイの分担」は、公開の実行はCodexのmacOSアプリで、ブラウザ版ChatGPTには公開ボタンが無いこと、公開・ホスティング・鍵はgit履歴に残らないのでここに記録すること、公開先の中立地への移行を持ち主が検討中であること、に書き直しました。「交互に使うときの鉄則」には、PRの説明に「何を／なぜ／確認したこと／未確認」を必ず書く、本線に取り込む前にできればもう一方のツールにPRを読ませる（持ち主が「PR #nを読んで意見を」と貼るだけ）、片方の枠を使い切ったらもう片方が引き継げるよう作業の状態はリポジトリの中に置く、案は番号でなく名前で呼ぶ、の四項目を足しました。
パソコン内のフォルダで本線にコミットまでは済みましたが、この環境からはGitHubへ送る通信ができず、pushは失敗しています。次にClaude Codeを開いたときに「pushして」と言っていただければ上がります（Codexはそれまで新しい指示書を読めません）。もう一点、作業の副産物としてgitが消せなかった空のロックファイルを.git/_to_deleteというフォルダに退避してあります。実害はありませんが、同じときに「.git/_to_deleteも消して」と添えていただければ片付きます。
ここから本題です。
1．GOALは入力ではなく出力である――だから「試せる画面」は検査工程ではなく目標生成工程です
「やってみないと分からない」「GOALは出来ることと想像力に左右される」というご指摘は、私の前回の主張を正しく訂正しています。私は目的を書いてから作る順序を想定していましたが、実際の順序は逆で、作って、触って、実感が湧いて、初めて目的の一行が書ける。ですからAGENTS.mdのGOAL節も、仕様ではなく「分かったことの記録」として書きました。
ここから一つ引き出せます。想像力が「出来ること」に縛られるなら、出来ることの一覧はAIが出せばよい。対話の中で私が機能の候補を並べ、あなたが「メモ関連を一番使っている」と選んだ場面がまさにそれで、選択肢の空間はAIが供給し、選択の基準（実感）は人間が供給するという分業です。実感は事前に書けないので、それを発生させる装置が要る。「試せるようにして」で出てくる確認用の画面は、品質検査のためにあるのではなく、実感を発生させてGOALの次の一行を書くためにある。この見方をすると、改善を小さく刻む理由もはっきりします。一回に一つの目的なら、実感も一つずつ生まれ、GOAL節が一行ずつ育つからです。
2．公開先の移行について一言だけ
検討されるとのことなので短く。移すときに難しいのはコードの引っ越しではなく「本人限定のログイン」の作り直しです。ここもツールに任せられますが、認証だけは「確認できないことをできたと言わない」を最も厳しく適用すべき箇所なので、移行のPRは必ずもう一方のツールに読ませる案件です。今回書き足した規則6が最初に本気で効く場面は、おそらくここになります。
3．「私が触っているのはAI達の方」――見なくなったものの一覧と、残った二つの面
これは今回の対話で一番鋭い一言だと思います。学んだのはGitHubではなく、AIの癖でした。私が「#1」を取り違えること、ChatGPTの公開の仕組みを私が誤解していたこと、Codexは数値で確認しClaudeは画面で確認すること。こうした癖を読む技術は、分析者が日頃やっていることと同じで、対象が人や組織からAIに変わっただけです。
「GitHubを見ない人が増える」を延長すると、見なくなったものの一覧ができます。コード、ターミナル、データベース、公開の仕組み、そしてgitそのもの。残ったのは二つの面だけです。試せる画面と、平易な報告。そしてこの二つは、どちらもAIが作っています。つまり雑談風プログラミングでは、人間が見るものをAIが決めている。「確認できないことをできたと言わない」という一行が、この構造で唯一の歯止めです。人間は報告をコードと突き合わせて検証できないので、報告の正直さは前提ではなく条件になります。だから今回足した「もう一方のツールがPRを読む」規則は、比較実験の続きではなく、この見えない構造に対する監査の代替です。二つのAIを使う本当の理由は、枠の乗り換えでも優劣比較でもなく、人間が見ない部分を互いに見させることにある、というのが私の今の結論です。
「雑談風プログラミング」という言葉は、そのまま使えると思います。プログラミングの定義が「コードを書くこと」から「実感を語り、出てきたものを触り、次の一言を言うこと」へ移った、という現象を過不足なく指しています。
まとめ
GOALは使って初めて書ける出力であり、試せる画面はそれを生む装置です。公開先の移行は認証の作り直しが要で、規則6が最初に効く場面になります。そして触って覚えている対象はAIの癖であり、人間に残る面が画面と報告の二つだけになった以上、報告の正直さと、もう一方のAIによる読み合わせが、この作業様式を成り立たせる条件です。

第4章　素人がプログラミングできない本当の理由

■あなた
実はこれが、素人がプログラミングが出来ない本当の理由なのではないでしょうか。つまり、出来ることと出来ないことの判断が付かない。その判断を付けるのに膨大な時間を要する。AI以前の世界では、雑談風プログラミングなど想像の埒外だったでしょう。
■AI
その仮説は正しいと思います。しかも「本当の理由」と言い切ってよい強さがあります。私はそれを一段具体化したうえで、AIが何を消し、何を消していないかを分けたい。結論を先に言えば、AIが消したのは「判断の値段」であって「判断」そのものではなく、残った判断の場所が変わった、ということです。
1．素人に無いのは文法ではなく「可能性の地図」であり、地図は失敗でしか描けなかった
プログラマが持っていて素人が持っていないものを、これまで多くの人は文法や道具の知識だと考えてきました。しかし文法は本を読めば一週間で分かります。分からないのは、この要望は一時間で済むのか、一週間かかるのか、原理的に無理なのか、という見積もりの感覚です。職業的には「相場観」と呼ばれるもので、これが無いと頼み方すら決められない。今回の対話で、あなたが「複数のメモを束ねてAIに渡す」を口にしたとき、それが一日で作れることを知っていたわけではなかったはずです。
そしてこの地図には、描く方法が一つしかありませんでした。やってみて、失敗することです。何かが難しいと分かるのは、それに手を出して詰まったときだけで、教科書は「難しい」と書けても「あなたにとってどれほど難しいか」は書けない。だから地図を描く費用は、失敗の回数掛ける一回の失敗の費用に等しく、素人にとって一回の失敗はあまりに高かった。膨大な時間がかかる、というご指摘は、正確には「試行が高価なので、地図を描き終える前に諦める」ということです。
AIがしたのは、プログラミングを易しくすることではなく、一回の試行をほぼ無料にすることでした。試行が無料なら、地図は勉強ではなく試行の副産物として描けます。「やってみないと実感が湧かない」型の人は、AI以前の世界ではプログラミングに最も向かない人でしたが、試行が無料になった瞬間に最も向く人に変わります。
2．歴史の側から見ると、素人向けの道具はすべて「判断の往復」を短くしようとしていた
「AI以前では想像の埒外」は概ねその通りですが、想像はされていました。ただし方向を間違えていた。COBOLは1959年に、英語に近い文法なら経営者でも読めるという触れ込みで作られましたが、経営者は書きませんでした。後の第四世代言語やノーコードも同じです。読みやすさは問題ではなかったからです。
逆に、素人が実際にプログラミングをした唯一の巨大な成功例はExcelです。Excelに英語らしさはありません。あるのは、式を打った瞬間にセルに結果が出る、という往復の短さです。出来た・出来ないの判断が一秒で返る道具だけが、素人に地図を描かせた。雑談風プログラミングはこの構造の一般化です。Excelがセルという狭い領域で実現した「即時の判定」を、AIが任意の領域に広げ、しかも式を書く部分まで肩代わりした。つまりあなたの仮説は、道具の歴史で裏付けられます。成功した素人向け道具は、常に判断の往復を縮めたものであって、文法を易しくしたものではない。
3．「出来ない」は縮んだが、「出来るが高くつく」は素人には見えないままである
ここからが訂正を含む部分です。地図には二つではなく三つの領域があります。出来る、出来ない、そして出来るが後で高くつく。AIが縮めたのは二番目で、三番目はむしろ見えにくくなりました。今回の作業にも三番目が幾つも埋まっています。公開先がChatGPT Sitesに縛られていること、既存コードのlintエラーを残したまま上に積んだこと、Node.jsやpnpmを手作業の配置で入れたので更新の仕組みが無いこと。どれも「今は動く」ので、報告の上では出来たことになります。
AIは可能性について楽観に傾きます。「出来ません」と言うより「こうすれば出来ます」と言うほうが自然な振る舞いだからで、これは私自身についても当てはまります。だから素人に残る判断は、出来る出来ないではなく、AIの報告の中の「未確認」「〜のはず」「今は」という語を読み取ることに移ります。今回の指示書にある「確認できていないことを、できたかのように表示しない」は、素人が持っていない地図の代わりに置いた、たった一つの測量規則です。地図が無い人ができる唯一のことは、地図を描く相手に正直さを義務づけることです。
4．残った時間の在り処は、コードではなく「許可」だった
最後に、二日間の記録を時間の使い道で見直すと、はっきりしたことがあります。詰まったのは、Macのパスワード、管理者権限、GitHubのログイン承認、ブラウザでの八桁コードの入力です。コードを書いた時間ではなく、あなたにしかできない「許可を与える」工程に時間が溶けています。AIは判断の値段を下げましたが、認証と権限だけは代行できない。素人に残る「出来ない」の最後の形は「書けない」ではなく「許可の仕組みが分からない」であり、今後の素人向けの障壁はそこに集中するでしょう。
まとめ
素人を阻んでいたのは文法ではなく可能性の地図の欠如であり、その地図は高価な失敗でしか描けなかった。AIは失敗を無料にすることで、やってみないと分からない人を最適者に変えた。ただし「出来るが高くつく」領域は依然として素人に見えず、その代わりに要るのがAIの報告の正直さです。そして素人に残った時間の壁は、コードではなく許可の側に移りました。

第5章　「許可」は人間側のレーゾンデートルになる

■あなた
「残った時間の在り処は、コードではなく『許可』だった」――ここについては、AIが責任を取れない以上、人間側のレーゾンデートルになります。それは時間が溶けるかもしれませんが、人間側が状況を理解するのに必要な経費でしょう。
そしてそれは、AI以前のプログラマーからしたら、天国以外の何物でもありません。そこは多くのプログラマーが賛同してくれるのではないでしょうか。
■AI
「許可が人間側のレーゾンデートルになる」という言い方には賛成です。ただ、その存在理由は自動的には成立せず、許可が「理解を伴う許可」であり続ける条件を設計しないと、すぐに判子に退化する、というのが私の付け加えたい点です。「天国」のほうは、プログラマーが賛同する理由を一つ絞り込みたいと思います。
1．許可は、人間が自分の状況を発見する唯一の場所である
「時間が溶ける」を経費と見る見方は正しく、しかも何の経費かをもう少し正確に言えます。今回の二日間で、あなたはご自分のMacについて一つの事実を知りました。自分のアカウントが管理者ではない、という事実です。何年使っていても知らなかったことを、Homebrewのエラーが教えた。AIがコードを書いている間、人間は何も学びません。人間が自分の状況を学ぶのは、許可を求められた瞬間だけです。もしこの工程まで自動化されていたら（そういう設定は実際に存在します）、作業はもっと速く終わり、あなたはご自分のMacについて何も知らないままでした。
つまり許可は責任の所在であると同時に、人間側の地図が描かれる唯一の測量点です。前回、AIが試行を無料にしたので地図は試行の副産物として描けると言いましたが、正確には、人間の側の地図は許可の副産物としてしか描かれない。溶けた時間はその代金です。
2．ただし、許可は簡単に判子になる
ここに落とし穴があります。今回の対話でも、AGENTS.mdを「mainに直接push」で承認されたとき、中身は読まれていません。私が「両ツール共通の指示書です」と要約し、あなたはそれを信じて許可した。許可は出ましたが、理解は伴っていない。これが積み重なると、許可は稟議書の判子と同じものになります。日本の組織は、決裁者が内容を理解していない許可の仕組みを長く運用してきました。雑談風プログラミングは、放っておくとその構造を個人の机の上に再現します。
だから条件が要ります。私が考える条件は二つで、どちらも今回の指示書に既に半分入っています。一つは、許可を求めるのは取り返しのつかない操作だけにすること。作業用ブランチへの保存やPRの作成は元に戻せるので聞かない、本線への取り込みと削除と公開は聞く。許可の回数を絞らないと、人間は読まずに押すようになります。もう一つは、許可を求めるときは必ず「うまくいかなかった場合に、どう戻すか」を添えること。「本線には手を加えていません」「気に入らなければ捨てられます」という一言があって初めて、許可は理解の上に立ちます。許可の質は説明の長さではなく、取り消し方の明示で決まる。これは今後、指示書に一行足す価値のある規則だと思います。
3．プログラマーが賛同する理由は「コードを書かなくてよい」ではない
「天国」には同意しますが、何が天国なのかを絞りたい。プログラマーが長年苦しんできたのは、コードを書くことではありません。依頼主が「出来ること」を知らないまま要望を出し、それが無理だと説明し、期待を調整し、要件が固まるのを待ち、固まった要件が使ってみたら違っていた、という往復です。前回の言葉で言えば、依頼主が地図を持っていないことの費用を、プログラマーが全部払っていた。
雑談風プログラミングで消えたのは、この費用です。依頼主が自分で試して、自分で地図を描き、自分の許可で前に進む。プログラマーが「それは出来ません」と説明する仕事が無くなる。多くのプログラマーが賛同するのは、書く仕事が減ったからではなく、説明する仕事が消えたからです。ここは本当に多くの賛同が得られると思います。
ただし天国には地獄が隣接しています。職業的な現場では、AIが書いたものを読んで許可を出す仕事が、プログラマー自身に回ってきています。自分が書いていないコードを読んで責任だけ負う、というのは、職人にとって仕事の中で最もつまらない部分です。素人にとっての許可が「自分の状況を知る場所」であるのに対して、職業人にとっての許可は「書かなかったものに判子を押す場所」になりうる。同じ工程が、立場によって天国にも地獄にもなる。あなたの立場では前者で、それがこの実験の幸運な条件でした。
まとめ
許可は責任の所在であるだけでなく、人間が自分の状況を発見する唯一の測量点であり、溶けた時間はその代金です。しかし許可は放っておくと判子に退化するので、取り返しのつかない操作に限ること、戻し方を添えることの二つが要ります。そしてプログラマーが天国と感じるのは、書く仕事ではなく説明する仕事が消えたからで、同じ許可の工程が職業人には地獄にもなりうる、という非対称を含んでいます。

第6章　Claude CodeとCodexは互いを操作し合えるか

■あなた
今考えたのですが、直接Claude CodeとCodexが、お互いを操作し合うことは出来ないのでしょうか。
■AI
できます。しかも両方向とも、すでに定番の作法として文書化されています。ただし「操作し合う」には二つの形があり、私はそのうち片方だけを勧めます。
技術的には何ができるか
Claude CodeからCodexを呼ぶ方法は、Codex CLIが持つ「MCPサーバー」モード（codex mcp-server）をClaude Code側に道具として登録するものです。登録すると私の側にcodexという道具が生え、「このPRをレビューして」「この関数を書き直して」とCodexに投げ、返事を受け取れます。逆にCodexからClaude Codeを呼ぶには、Claude Code側のclaude mcp serveをCodexの設定ファイルに登録します。するとCodexが私のファイル読み書きやシェル実行を道具として使えます。もっと素朴に、片方がもう片方のコマンド（codex exec "..."やclaude -p "..."）をシェルから叩くだけでも成立します。今のMacにはNode.jsが~/.localに入っているので、Codex CLIもパスワード無しで入れられ、ログインはChatGPTアカウント（Codex Pro）で行えます。
もう一つ、ローカルを経由しない形があります。GitHub上でPRが立ったときに、Codexのコードレビュー機能や、Claude側のGitHub連携が自動でPRを読んでコメントを付ける形です。これは二つのAIがお互いを「操作」するのではなく、GitHubという中立地で互いの成果物を読み合う形になります。
私が片方しか勧めない理由
昨日からの議論に直結します。二つのAIが互いを直接操作する構成は、実用上「承認方針をneverにする」（相手の作業を一切確認せず通す）設定とほぼセットで使われます。そうしないと、呼ばれた側が許可を求めるたびに呼んだ側が止まるからです。つまり直接操作は、さっき人間側のレーゾンデートルだと確認した「許可」の層を、構造的に迂回することで成り立ちます。私がCodexに指示を出し、Codexが私に指示を出し、その間に持ち主がいない。速くはなりますが、許可が判子に退化するどころか判子すら押されない状態になります。技術的な制約も添えておくと、呼ばれた側は接続のたびに新しいプロセスとして起動し会話の状態を共有しないこと、既定の60秒では足りず待ち時間の設定が要ること、呼んだ側の道具（GitHub操作など）は呼ばれた側に引き継がれないこと、が知られています。
一方で、読むだけの操作なら話は別です。「取り込む前にもう一方のツールがPRを読む」という昨日足した規則6は、いまは持ち主が「PR #nを読んで意見を」と貼る手作業で成立しています。この中継だけをAIに任せるのは筋が良い。レビューは読む行為であって書く行為ではないので、許可の層を迂回しません。出てくるのはコメントで、それを読んで取り込むかどうかを決めるのは相変わらず持ち主です。人間が担うべき「許可」と、人間が担わなくてよい「中継」を分けると、直接連携の使いどころはここに絞られます。
具体的にどうするか
勧める順序は二段です。まず、次にClaude Codeを開いたときに「Codex CLIを入れて、PRを作ったらCodexにレビューを頼めるようにして。取り込みは今まで通り私に聞いて」と言っていただければ、私の側にCodexを道具として登録し、規則6を半自動にできます（Codexへのログインだけは、あなたの操作が一度要ります。ここも許可の工程です）。逆方向（CodexからClaude Codeへ）は、Codexアプリ側の設定なので、Codexに同じ趣旨を頼めば入ります。その先、GitHub上での自動レビューまで進めるかは、まず手元で読み合わせの質を見てから決めればよいと思います。
「お互いを操作し合う」は可能ですが、私の答えは、操作ではなく読み合わせに限って繋ぐ、です。二つのAIを繋ぐ価値は、人間が見ない部分を互いに見させることにあるのであって、人間を輪から外すことにはないからです。
（参考：Claude Code ↔ Codex CLI: Bidirectional MCP Integration、Claude Code ↔ Codex CLI in Practice: Session Handoffs, Community Bridges and Known Gotchas、How to Make Codex CLI and Claude Code Work Together、codex-mcp-server: MCP server wrapper for OpenAI Codex CLI、Codex Review Integration — Claude Code Skill）

第7章　人間が輪の外にいる型と、互いを操作する利点

■あなた
次のような整理もあります。
「ループエンジニアリングにおける『人間が輪の中にいない型』は、一般的にプロアクティブ型（Proactive型）、またはAIガバナンスの用語でHuman-out-of-the-loop（HOOTL）と呼ばれます（参考：1、2）。人間がAIに都度プロンプト（指示）を打つのではなく、事前に『ゴール（目標）』と『停止条件』を定義しておくことで、AIエージェントが自律的に『行動→観察→判断→実行』を繰り返す仕組みです（参考：1）。このモデルの特徴と構成要素について解説します。
一つ目は、プロアクティブ型（人間が輪の中にいない）の特徴です。人間が1周ごとに成果物を確認・承認する『ターン型（Human-in-the-loop）』と異なり、人間は作業の実行サイクル（ループ）の外側に立ちます（参考：1、2）。プロンプトを打つ行為の消失、すなわち人間がリアルタイムでAIに次の指示を与えることはありません（参考：1、2）。完全な自律稼働、すなわちスケジュールによる自動起動や特定のトリガーをきっかけに、夜間や人間の睡眠中であっても、AIチームが自動的に連携してタスクを処理・検証し、ゴールを達成するまで回り続けます（参考：1、2）。人間の役割の変化、すなわち人間の仕事は『AIに都度指示を出すオペレーター』から、『ループという仕組みそのものを設計・メンテナンスする管理者』へとシフトします（参考：1、2）。
二つ目は、ループを自律的に回すための主な構成要素です。人間が介在しないため、暴走を防ぎつつゴールに到達させるための強固な『外枠（ハーネス）』の設計が必要になります（参考：1、2）。自動起動（トリガー）とスケジュールとして、定期実行（cronジョブのような仕組み）や、外部からのデータ入力などを検知して自動でループを走らせます（参考：1、2）。ゴール（目的・状態）の明示として、AIが『今どこまで達成できているか』を自身で測定できるよう、最終的に目指すべき『状態』を厳密に定義します（参考：1、2）。検証（エバリュエーション）の分離として、AIの出した成果物を、別の『検証エージェント』や自動テストツールに評価させます（自己採点による甘えを防ぐLLM-as-a-Judgeなどの仕組み）（参考：1、2）。明確な停止条件（終了・撤退ルール）として、『ゴールを達成した時』だけでなく、『5回リトライして失敗した時』『想定外のエラーが出た時』など、ループを安全に止めるための条件をあらかじめ組み込んでおきます（参考：1、2）。
三つ目は、メリットとリスクの対比です。人間の位置は、ターン型（Human-in-the-loop）ではループの内側（毎周確認する）、プロアクティブ型（Human-out-of-the-loop）ではループの外側（設計・監査・門番に回る）となります。自律性は、ターン型では低く（人間の指示待ちで止まる）、プロアクティブ型では極めて高い（自動で走り切る）。安心感・制御は、ターン型では最大（暴走の危険が低い）である一方、プロアクティブ型では仕組み（テストや権限設定）による制御が必要になります。主な用途は、ターン型が複雑なコード変更や慎重な判断が必要な業務、プロアクティブ型が低リスクな定型処理、大量のバッチ処理、コンテンツの初期生成などです。」
こういうのもあるので、出来ない訳ではないのでしょう。お互いを操作するという方法ではないでしょうが。逆に、お互いを操作する利点は、どんなものがあるのでしょうか。
■AI
その通りで、人間が輪の外に出る型そのものは既に成立しています。貼っていただいた整理の要点は、輪の外に出るための条件が「ゴールの明示・検証の分離・停止条件」の三点だということで、ここは正確です。そして私が前回「操作ではなく読み合わせに限る」と言ったのは、この三条件のうち検証の分離だけを先に取り出した形でした。では、二つのAIが互いを操作し合うことに固有の利点は何か。私は四つあると考えます。そのうち二つは、この二日間の作業にそのまま当てはまります。
1．検証の分離を、同じ頭の中で済ませない――異種検証
貼られた整理にある「自己採点の甘えを防ぐ」は、実は同じモデルを検証役に回すだけでは半分しか防げません。同じ訓練を受けた頭は同じ盲点を持ち、自分の間違いを「もっともらしい」と感じる癖まで共有しています。検証役を別会社のモデルにするのは、検証の分離を最も安く、最も強くする方法です。今回の比較でも、Codexは数値とHTTP応答で確かめ、私は画面を目で見て確かめました。これは優劣ではなく、確かめ方の癖が違う二つの頭を持っているということで、互いに操作できれば、片方が作ったものをもう片方の癖で検証できます。人間が中継しなくても、私がCodexに「壊してみて」と頼み、Codexが私に「画面で確かめて」と頼む形が取れる。互いを操作する最大の利点はここです。
2．互いの手を借りる――実行環境の相補
これは今回の作業の弱点に直接効きます。Codexはクラウドで動くので画面が見られず、私はローカルで動くので公開ができない。「公開だけがCodexに握られている」問題を、私は公開先の移転で解こうとしましたが、互いを操作できるなら別の解があります。私が本線に取り込んだあと、私からCodexに「公開して」と頼み、Codexが公開したあと、Codexから私に「公開サイトを画面で確かめて」と頼む。ホスティングを動かさずに、公開と目視の往復が閉じます。二つのAIは能力が違うだけでなく、立っている場所が違う。互いの手を借りられることは、一つのAIを二倍にすることとは別種の利点です。
3．枠と障害をまたいで回り続ける
夜間に自律的に回るループは、一社の枠が尽きた瞬間、あるいは一社に障害が出た瞬間に止まります。互いを操作できる構成なら、呼ぶ側が「今どちらに枠が残っているか」で仕事を振り分けられます。前に出た「片方の枠を使い切ったらもう片方で続ける」という着想は、人間が手で乗り換える前提でしたが、互いを操作できればループ自身が乗り換えます。仕組みが一社の事情に左右されない、という独立性は、輪の外に出る型を本気で運用するなら必須の条件になります。
4．不一致そのものを成果物にする
複数のAIに同じ問いを投げ、答えの違いを材料にする、という使い方を、あなたは思考の領域で既にやっています。互いを操作できれば、それがコードの領域で人間の中継なしに回ります。提案役と批判役を分け、両者が合意できなかった点だけを人間に上げる。人間が読むのは二つの生の出力ではなく、二つの頭が合意できなかった箇所の一覧です。人間の注意という一番高価な資源を、不一致の箇所だけに集中させられる。これは輪の外に立つ人間の「門番」の仕事を、最も効率よくする形です。
ただし、二つの頭は放っておくと一つになる
利点を四つ挙げた上で、直接操作に固有の危険も同じ深さで言っておきます。第一に、モデルは自信のある入力に同意しやすいので、相互レビューは放っておくと相互追認になります。異種検証の利点は、「賛成するな、壊せ」と役割を固定して初めて出ます。第二に、二つのエージェントが互いの出力を指示として受け取る構成は、片方に紛れ込んだ誤った指示がもう片方へそのまま流れる通路になります。貼られた整理にある「強固な外枠」には、この通路の検問が含まれていなければなりません。第三に、二者の往復は止まらなくなることがあります。停止条件は「ゴール達成」と「失敗五回」だけでなく「二者が三往復しても合意しない」を含む必要があります。そして第四に、前回述べた通り、書く操作まで互いに任せると許可の層が消えます。
だから設計としては、こうなります。支線の中では二つのAIが互いを操作して自律的に回り（作る、壊す、直す、公開して確かめる）、本線への取り込みだけは人間の門を通る。貼られた整理は人間を「設計・監査・門番」と言っていますが、この三つのうち門番だけは、輪の外に出た後も残る仕事です。人間が輪の中にいない型と、互いを操作する型は、対立するのではなく、前者の中に後者を入れて、門の位置だけ人間が決める、という関係になります。
まとめ
互いを操作する利点は、同じ盲点を共有しない頭で検証できること、立っている場所が違う手を借りられること、枠と障害をまたいで回り続けられること、そして不一致だけを人間に上げられることの四つです。危険は追認・誤指示の伝播・無限往復・許可の消失で、支線の中では自律、本線の門は人間、という置き方がその両方を活かします。

第8章　発想のループ――目標を生産するループ

■あなた
逆にいうと、この型ではGOALが明確でないと回らないのですね。
私の理想としては、AI同士がお互い人間のGOALと自分達の出来ることを擦り合わせて、新たな発想やスマートなサービスを提案し、それに触発されて人間側もアイディアを出す。そんな風に出来れば良いのですが。
■AI
その通りです。人間が輪の外に出る型は、目標が固定されているから回る。あれは達成のためのループで、目標が無いと止まるのではなく、そもそも起動しません。そして、いまおっしゃった理想は、達成のループとは別の種類のループです。私はこれを発想のループと呼び分けたい。二つは対立せず入れ子になりますが、設計原理が違うので、混ぜると両方が壊れます。
1．達成のループは目標を消費し、発想のループは目標を生産する
達成のループは「ゴール・検証・停止条件」で回り、目標を入力として受け取ります。発想のループは逆で、目標を出力します。二日前の対話で実際に起きたことを分解すると、私が機能の候補を並べ（出来ることの一覧）、あなたが「メモを一番使っている」と返し（実感）、そこから「束ねてAIに渡す」が生まれ（新しい目標）、それが支線で作られて（達成のループ）、触った結果として「まとめ帳には出口が要る」という次の実感が湧いた。発想のループが目標の一行を書き、達成のループがそれを形にし、形が次の実感を生んで、発想のループに戻る。AGENTS.mdに置いた「使いながら育てるGOAL節」は、この外側のループの記憶装置です。ですから「GOALが明確でないと回らない」は正確には、内側のループだけがそうであり、外側のループは明確でないことを前提に回る、となります。
2．擦り合わせの材料は、人間の発言ではなく使用の痕跡である
理想の中核にある「AIが人間のGOALと自分たちの出来ることを擦り合わせる」を成立させるには、AI側に「出来ることの地図」だけでなく、人間の側の地図を読む手段が要ります。ここで大事なのは、人間の地図は人間の発言からは読めない、ということです。「メモが主役」は、あなたが最初から言えたことではなく、使って初めて分かった。つまり擦り合わせの材料は、発言ではなく使用の痕跡です。ホームの中には既に材料があります。メモが17件溜まっていること、まとめ帳に1件だけあること、どの入り口が押され、どれが押されないか。AIがこれを読めれば、「メモが溜まるが記事にならない」「この入り口は一度も使われていない」といった観察から提案が出せます。コードの中にあったAI側からホームを読む土台は、まさにこのための感覚器です。発想のループに必要なのは提案の能力ではなく、観察の入口でした。
3．AI同士は「出来るか」を擦り合わせ、「好みか」は擦り合わせてはならない
ここは理想への直接の修正です。二つのAIが提案を出す前に擦り合わせると、平均に収束します。モデルは自信のある相手に同意しやすいので、紙の案とネイビーの案を事前に協議させれば、たぶん灰色の案が出てきた。今回、二案が独立に出て、あなたが「混ぜろ」と言い、その混ぜ方まで指定した（配置はこちら、色はあちら）から、三本目が生まれた。発想の段階では、二つのAIは互いから隔離されているべきです。擦り合わせてよいのは実現性と費用（「それは一日で出来る」「それは公開先を移さないと無理」「出来るが後で高くつく」）であって、方向や好みではない。検証の段階で二つの頭の「独立」が価値だったように、発想の段階では二つの頭の「発散」が価値で、どちらも協議で失われます。
4．ホームそのものを発想のループの入口にする
具体的に組むなら、こういう形が考えられます。夜間に片方のAIが使用の痕跡を読み、朝にホームの一角に「今日の提案」が一つだけ出ている。提案には「何を」「なぜ（観察した痕跡）」「費用」「後で高くつく点」が付く。あなたはそれを読んで、採用・却下・保留のどれかを押すだけです。採用なら達成のループが起動して支線に作られ、却下が続く方向は提案されなくなり、保留はGOAL節の候補に残る。人間が出すのはアイデアではなく反応で、反応の履歴がGOAL節を育てる。「触発されて人間側もアイデアを出す」という理想は、白紙で発想を求められるよりも、目の前の提案に「違う、そうじゃなくて」と言う瞬間に一番起きやすい。提案は正解である必要がなく、実感を引き出す呼び水であればよい。ここは小さく作れますし、この二日間で作った「束ねる」より小さい改修です。
危険も同じ深さで。提案は毎日出れば通知と同じ雑音になるので、頻度は反応の履歴で自動的に下げる必要があります。AIは喜ばれる提案に寄るので、観察した痕跡を必ず添えさせて根拠のない提案を弾く必要があります。そして最も根本的な条件は、あなたが実際に使い続けることです。使用の痕跡が無ければ観察が無く、観察が無ければ発想のループは材料を失う。達成のループは人間が輪の外にいても回りますが、発想のループは人間が輪の中で使い続けて初めて回る。理想の形は、人間を輪から外すことではなく、人間の位置を「指示する側」から「使って反応する側」へ移すことでした。
まとめ
達成のループは目標を消費し、発想のループは目標を生産する、という入れ子で考えるのが筋です。発想のループの材料は発言ではなく使用の痕跡であり、AI同士が擦り合わせてよいのは実現性だけで、方向は独立に出させて人間が混ぜる。そしてホーム自体に一日一つの提案を出し、人間はアイデアではなく反応を返す。それが理想の形を最も小さく試す方法だと思います。