ClaudeとChatGPTを抱き合わせて使う｜2つの本家AIを「制作チーム」にする方法
はじめに
私は現在、ClaudeとChatGPTを「どちらか1つ選ぶ」のではなく、得意分野に応じて組み合わせて使っています。
対話や企画、文章の整理はClaude。実装、ファイル操作、画像生成、外部ツールとの連携は、ChatGPT側のCodex。さらに重要な成果物は、制作担当とは別の監査役が確認します。
この記事でいう「ChatGPT側」とは、OpenAIのCodexアプリ／Codex機能を指します。ClaudeとChatGPTが公式機能で直接同期するという意味ではありません。
Claude Codeは、Claudeがコードやファイルを読み、編集やコマンド実行まで行うためのAnthropic製ツールです。CodexはOpenAIのコーディングエージェントで、ChatGPTと同じOpenAIが提供していますが、この記事では主にCodexアプリを使っています。
つまり、2つの本家AIを別々の便利ツールとして使うのではなく、役割を持った1つの制作チームとして動かす運用です。
ただし、最初からこの形にたどり着いたわけではありません。
少し前、私はClaude CodeとCodexを1つの画面から動かす、自分専用のAIアプリを作りました。
名前は「Duet」。
自然な言葉で依頼すると、文章や企画が得意なAIと、実装やファイル操作が得意なAIが役割を分け、最後は独立した監査役が成果物を確認する。そんな「AI制作チームの専用入口」を目指したアプリです。
テストを重ね、安全設計を見直し、いったんは完成と呼べるところまで作りました。
そして、完成と呼んだ直後にDuetをやめました。
自作アプリの中でAIがまったく動かなかったからではありません。
最大の理由は、DuetからWordPressや外部サービスへ実用的に接続できず、記事や画像を実際の仕事へ届けるところまで完結できなかったからです。
本家アプリの進化は、Duetをやめた主因ではありません。外部へつながらない自作アプリを直し続けるより、本家アプリを入口にして必要な接続だけを整える方がよい。その判断を後押しした要因でした。
現在は、OpenAIのCodexアプリとAnthropicのClaudeアプリ／Claude Codeを、それぞれ正式な入口として使っています。どちらから依頼しても同じルールと記憶を参照し、得意分野に応じて仕事を引き継ぐ形です。
この記事では、ClaudeとChatGPTをどう役割分担させ、同じルールと記憶を共有する「AI制作チーム」として使っているのかを紹介します。その背景として、Duetを作り、完成後に手放した経緯も振り返ります。
これは「自作アプリ開発に失敗した話」というより、作ることが目的になりかけた時に、本来の目的へ戻った話です。
そもそも、なぜDuetを作ったのか
AIを使う場所が増え、仕事が分断されていた
私は理学療法士として臨床に立ちながら、ブログ、X、note、研修資料などを制作しています。
これらの仕事を支えるために育ててきたのが「G-System」です。
G-Systemでは、Claude Code側の人格をCle.V.I.S.（クレア）、Codex側の人格をCo.V.I.S.（コービス）と呼び、役割を分けています。
- クレア：対話、意図整理、企画、構成、文章、臨床推論
- コービス：実装、ファイル操作、画像・文書生成、検証、外部ツール連携
- JUDGE：制作側とは別の読み取り専用プロセスで品質を監査
当初はSlackやターミナルなど、仕事ごとに入口が分かれていました。
ブログ本文はここ、画像はここ、実装はここ、という具合です。AI側には分かりやすくても、依頼する私は会話を移動し、前提を説明し直さなければなりません。
欲しかったのは、すべてを1つの会話から頼める入口でした。
そこで、Claude CodeとCodex CLIを裏側で呼び分けるローカルアプリ「Duet」を作り始めました。
Duetで実現しようとしたこと
Duetの構想は単純でした。
私が1つのチャットで依頼する
↓
AIが内容を判断する
↓
企画・文章はクレア
実装・ファイル操作はコービス
↓
重要な成果物は独立JUDGEが監査
↓
合格した結果だけを私へ返す
さらに、一方のAIが利用上限や一時的な障害で使えない場合は、もう一方が仕事を引き継ぐ仕組みも加えました。
目指していたのは、AIを切り替えるための便利な画面ではありません。
複数のAIが同じルールで動き、途中で仕事を落とさず、完成条件まで追跡するチームの入口でした。
Duet開発で起きた3つの手戻り
1. 正式ルールがあるのに、アプリ専用ルールを作った
G-Systemには、AIの人格、役割分担、安全ルール、監査、成果物の保存先まで定めたAGENTS.mdがあります。これはチーム全体が参照する唯一の正本です。
しかし、Duetの初期実装では、その内容を短くまとめた「Duet専用ルール」をコード側へ持たせていました。
短い方が効率的に見えますが、正本が更新されるたびにコピーとの食い違いが生まれます。
そこで、Duet専用の人格や運用ルールをやめ、実行時にAGENTS.mdそのものを読む方式へ変更しました。
この時に得た教訓は、以前の記事の中心にもなった言葉です。
正本があるなら読め。別に作るな。
2. 監査を依頼しただけで「完了」にしていた
初期フローでは、JUDGEへ監査を渡した時点で元の仕事を完了扱いにしていました。
しかし、監査結果がFAILなら修正が必要です。証拠不足ならBLOCKEDとなり、完成とは呼べません。
そこで、監査を開始するだけでなく、結果が返るまで同じ仕事として追跡し、FAILなら制作側へ戻して修正後に新しいJUDGEで再監査する形へ直しました。
「依頼した」と「完了を確認した」は違う。
これはAI開発だけでなく、臨床や日常業務にも通じる考え方でした。
3. テストが通っても、設計全体が正しいとは限らなかった
Duetは多数の自動テストを通過しました。それでも独立JUDGEは、監査結果と元タスクのひも付けや、停止と完了が競合する可能性など、制作側だけでは見落とした問題を指摘しました。
自動テストは、決めた条件を繰り返し確認するのが得意です。
一方、独立監査は「そもそも確認条件が足りているか」を別の視点で見ます。
この経験から、コードが動くこと、テストが通ること、成果物を安全に完成扱いできることは、それぞれ別だと学びました。
完成と呼んだ直後、Duetをやめた
一番の理由は、WordPressや外部サービスにつながらなかったこと
Duetをやめた最大の理由は、本家アプリに欲しい機能がそろっていたからではありません。
DuetからWordPressや外部サービスへ、実用的に接続できなかったからです。
Duetの中では、Claude CodeとCodexを呼び分け、文章を作り、ファイルを扱い、監査まで進められるようになりました。しかし、ブログをWordPressの下書きへ反映する、画像をアップロードする、Webやブラウザを使って外部の情報やサービスへつなぐ、といった「制作の出口」がほとんど機能しませんでした。
記事を書けてもWordPressへ渡せない。画像を作れても投稿へ設定できない。外部サービスを使う工程へ進むと、結局はDuetの外へ出て作業をやり直す必要がありました。
1つの画面にAIを集めても、成果物を実際の仕事へ届けられなければ、制作システムとしては完結しません。
言い換えると、Duetには「AIへ頼む入口」は作れても、仕事を完了させる出口を作れなかったのです。
本家アプリの進化は、主因ではなく後押しだった
その一方で、Duetを作っていた間にも本家のAIアプリは進化していました。
OpenAIのCodexアプリでは、ファイル操作、Webやブラウザ、各種ツールとの連携を本家の環境で利用できます。現在はG-System側に安全な接続経路を用意し、WordPress下書きへの反映もCodex側から行えるようになりました。
ここで、厳しい問いが生まれました。
「外部へつながらないDuetを直し続けるより、本家アプリを入口にして必要な接続だけを整える方が、本来の仕事を前へ進められるのではないか」
独自アプリで外部接続まで抱えれば、認証、権限、APIの仕様変更、ブラウザ操作、セキュリティまで自分で保守し続ける必要があります。本家アプリの機能と更新へ追従する負担も増えていきます。
私はソフトウェア製品を販売したいわけではありません。
本来の目的は、臨床と情報発信を支えるAI制作チームを、自然に使えるようにすることです。
そう考えると、答えは明確でした。
入口は本家に任せる。自分たちは、役割、記憶、安全な引き継ぎ、品質基準の設計に集中する。
「もったいない」より、目的に合っているか
Duetには時間をかけました。多数のテストを作り、何度も監査し、安全な承認フローまで実装しました。
だからこそ、「ここまで作ったのだから使い続けたい」という気持ちもありました。
しかし、投入した時間は、これからも同じものを使い続ける理由にはなりません。
必要なのは、過去の労力を正当化することではなく、現在の目的に最も合う形を選ぶことです。
DuetのGUI、独自セッション、承認画面、エンジン切替機構は終了しました。一方で、開発中に磨いたWordPress下書きの安全機構、共通正本、引き継ぎルール、監査設計はG-Systemへ残しました。
アプリを捨てても、学びと安全核は捨てていません。
現在の形｜CodexとClaude、どちらからでも始められる
親になるのは、最初に依頼を受けた側
現在は、CodexアプリとClaudeアプリ／Claude Codeを、対等な正式入口として使っています。
私
├─ Codexから依頼
│ ├─ コービスが親として整理・実行・最終報告
│ └─ 企画・文章・複雑な判断はクレアへ相談
│
└─ Claudeから依頼
├─ クレアが親として対話・企画・執筆・最終報告
└─ 実装・大量ファイル操作・文書生成はコービスへ引き継ぎ
どちらの入口でも
→ 同じAGENTS.md、共有記憶、スキル、成果物を参照
→ 重要成果物は独立JUDGEが監査
ここでいう「連携」は、ClaudeとCodexに最初から備わった公式の相互接続機能という意味ではありません。
同じ作業フォルダにある正本、共有記憶、スキル、引き継ぎメモを使い、Codex側からClaude Codeへ読み取り専用で相談する経路を用意した、G-System独自の運用です。
Claude側からCodexへ同期的に呼び出す経路は、現時点では整備していません。実装作業を渡す時は共有フォルダの引き継ぎメモを使います。即時性が必要な場合や片方が使えない場合は、動いている側が得意分野を越えて最後まで担当します。
つまり、完全に左右対称な技術構成ではありません。
それでも、「どのアプリから始めても同じチームとして仕事が進む」という体験は実現できました。
本家アプリの強みを消さなくてよくなった
Duetでは、Claude CodeやCodexを自作アプリの内側から呼んでいました。そのため、本家アプリが持つ画面、ツール、タスク管理、更新機能を十分に生かせない場面がありました。
現在は、CodexならCodexのスレッド管理、ファイル操作、Web、スキル、各種連携をそのまま使えます。Claude側も、Claudeの対話や文章整理の強みを、本家の環境で直接使えます。
両者を無理に同じ画面へ押し込めるのではなく、それぞれが得意な場所で働き、共通の正本と成果物でつながる形です。
Duetを作ったことは無駄だったのか
答えは、はっきり「いいえ」です。
Duetを作らなければ、私は次のことをここまで具体的に理解できなかったと思います。
1. UIより先に、正本と役割を決める
見た目が1つになっても、AIごとのルールや記憶が食い違えばチームにはなりません。
重要なのは、チャット画面の統一より、何を正しい情報源とするか、誰が何を担当するか、どの条件で仕事を引き継ぐかです。
2. 自作すべきなのは「差分」だけ
本家が優れた入口、タスク管理、権限制御を提供しているなら、そこを作り直す必要はありません。
自分の仕事に固有なのは、人格、制作手順、保存先、WordPressの安全境界、監査ルールなどです。
既製品で足りる部分は本家へ任せ、自分にしか必要のない差分だけを作る方が、保守しやすく壊れにくい仕組みになります。
3. 「完成品を捨てる」ことも設計判断
作ったものを残すことだけが成果ではありません。
試作によって要件が明確になり、より単純で強い構成へ移れたなら、その試作は役目を果たしています。
Duetは、最終製品ではなく、G-Systemの本当に必要な部分を見つけるためのプロトタイプだった。今はそう捉えています。
理学療法士がAIシステムを作る意味
私はソフトウェアエンジニアではありません。
それでも、自分の仕事の流れは分かります。
どこで説明が重複するのか。何をAIへ任せたいのか。どこから先は人間が確認すべきか。何をもって完成とするのか。
こうした現場の要件を言葉にできれば、AIと一緒に仕組みを作れます。
そして、作った仕組みが目的からずれた時には、手放す判断もできます。
リハビリでも、最初に立てた仮説へ固執せず、反応を見て介入を変えます。Duetから本家アプリ連携へ切り替えた過程も、それと似ていました。
大切なのは、自分の最初の案を守ることではありません。
目的に対して、いまの方法が本当に合っているかを再評価し続けることです。
まとめ
Claude CodeとCodexを1つにまとめるために作ったDuetは、完成後に運用を終了しました。
現在は、CodexアプリとClaudeアプリ／Claude Codeをそれぞれ正式な入口とし、同じAGENTS.md、共有記憶、スキル、成果物、独立JUDGEでつないでいます。
この転換から得た教訓は、次の3つです。
- 正本があるなら、コピーを作らず直接読む
- AIを動かす入口だけでなく、WordPressや外部サービスへ届ける出口まで設計する
- 完成させたものでも、目的に合わなければ手放す
Duetをやめたことは、開発の敗北ではありません。
自作アプリを完成させることから、AIチームで仕事を前へ進めることへ、目的を戻した判断です。
いまのG-Systemは、以前より画面が少なく、構成も単純です。
それでも、クレアとコービスの役割、共有する記憶、完成を守るJUDGEは残っています。
良い仕組みとは、作ったものが多い仕組みではなく、目的に必要なものだけが残っている仕組みなのだと思います。
関連記事
AIや自動化を仕事へ取り入れる過程は、こちらの記事でも紹介しています。
- 【理学療法士が使ってみた・PR】AIスライドツール「イルシル」で勉強会資料の作成負担を大幅に軽減した話
- 【令和6・8年度対応】EMシステムズでデータ提出加算を自動集計する方法｜年間90万円を取りこぼさないために
書類業務を効率化したい方へ
書類業務の効率化に関心がある方には、こちらのnoteも用意しています。
参考情報
- Introducing the Codex app（OpenAI）（2026年7月21日確認）
- Claude Code overview（Anthropic）（2026年7月21日確認）
本記事で紹介したDuetは、著者が個人利用のために制作し、すでに運用を終了したローカルアプリです。現在のClaudeとCodexの連携も、両社が公式に提供する製品間連携ではなく、著者のG-System内で構成した独自運用です。各サービスの仕様、利用条件、利用上限は変更されることがあります。
著者：Goyasu（Yasuyasuuun）｜理学療法士
外来リハビリに従事しながら、ブログ・X・noteでリハビリ情報とAI活用の実践を発信しています。
本記事は、既存のDuet開発記事をもとに、Co.V.I.S.が再構成・改稿とWordPress反映を担当し、Cle.V.I.S.が構成・文章品質をレビューしました。
 | アナトミー・トレイン第3版 徒手運動療法のための筋筋膜経線 [ トーマス・W．メイヤーズ ] 価格:7,150円 |
