この記事のまとめ
ChatGPT Plusでできるのは、質問に答えてもらうことだけではありません。相談しながら仕様を決め、調査し、コードや資料を作り、不具合を直し、結果を確かめる。そんな「チャットを使った開発」を、私はAD&Cという個人プロジェクトで試しています。
さらに最近は、AIに役割分担までさせています。リーダーが仕事を決め、配達係が別チャットに依頼を届け、担当AIが作業し、定期巡回が結果と積み残しを回収する仕組みです。まるで小さな開発チーム。でも実際に回してみると、AIが増えるほど「誰が配った？ 誰が受け取った？ 終わったの？」という問題が出てきました（笑）。
今のところ、個々の工程には動いた実績があり、全体の連続運転には未解決の問題があります。 それでも、失敗を記録して次の修正につなげられるところまで進みました。今回は、完成した魔法の仕組みではなく、ChatGPT Plusで開発を続けるために組み立てた「実際のやり方」を紹介します。
図：各工程には実動実績があるが、全体の無人連続運転は未実証。
さて、次の項からは、実際に困っている/やってみたい‼︎人向けに詳しく説明していきます‼︎
「チャットを活用した開発」とは、コードを書かせるだけではない
ここで言う開発は、AIにプログラムを一発で書かせる話ではありません。
「こういうものが欲しい」から始まり、相談して仕様を決める。試作品を作る。動かない理由を調べる。必要な部分を直す。結果をGitHubや文書に保存し、別のチャットでも続きから取りかかる。この一連の流れを、人間とAIの会話を中心に進めることです。
私が開発しているAD&C（AI-DODAI & Continuity）は、その実験場でもあります。目標は「AIを替えても、冒険は続く」。AIの記憶だけに任せず、決定事項、手順、成果物、未完了の仕事を人間が管理できる場所に残す考え方です。専門外の人でも、次の一歩が分かるカーナビのような仕組みを目指しています。
そのため、開発で大事にしているのは、AIの返答が立派かどうかよりも、実物ができたか、保存できたか、後から確かめられるかです。
AIを増やす前に「役割」を分けた
現在試している構成は、ざっくり次のようになっています。
| 役割 | やること | やらないこと |
|---|---|---|
| 私（人間） | 目的と優先順位、重要な採否を決める | 全案件の伝言係を毎回引き受けない |
| 開発リーダーチャット | 全体構想、採用済み判断、方向修正 | すべての実務を一人で抱え込まない |
| 定期巡回 | 既存案件を点検し、必要な修復、指示書準備、報告回収をする | 同じ問題を別案件として増殖させない |
| 5時間ごとの案内タスク | 準備済みの配送指示を必要時に提示する | 勝手にWorkを起動したことにしない |
| ChatGPT Work | 新しい担当チャットを作り、短い起動指示を配達して控えを残す | 実装、戦略判断、成果回収まで背負わない |
| 担当チャット（A/B/C） | 指示書を読み、実務・検収・保存・担当先への報告を行う | Workへ成果を送り返して回収を待たない |
| GitHub・共有KB | 仕様、判断、成果、未完了の状態を残す | その場の会話だけを唯一の正本にしない |
Aは戦略、Bは実務、Cは任意のブログ・利用事例制作です。これはChatGPTに標準で搭載された組織図ではなく、私がChatGPT Plusと保存先を組み合わせて決めた運用ルールです。
なぜWorkは「配達だけ」なのか
ChatGPT Workには、クラウド上のブラウザでサイトを操作する機能があります。幅広い仕事を任せられる機能ですが、AD&Cではあえて用途を絞りました。
最初からWorkに「案件を選んで、指示を作って、チャットを起こして、開発して、報告を集めて」と全部頼むと、何かが止まったとき原因の切り分けが難しくなります。そこで、Workは封筒を届ける郵便配達員にしました。封筒の中の仕事を決めるのはリーダー、仕事をするのは担当、結果を集めるのは巡回です。
Workは案件ごとに新規チャットを開き、「この指示書を読んで実行してください」という短い一行を送る。送信先URLと成否を控えたら仕事は終了。配達員が荷物を開けて組み立て始めない方式です（笑）。
この「配達専用」はAD&Cの設計判断であって、ChatGPT Work自体が配送しかできないという意味ではありません。
開発はどう回る？ 現在の実行フロー
- 定期巡回が未完了を点検する。 GitHubのIssueや共有KB、過去の担当報告を見て、既に終わった作業や別の担当が進めている作業を除き、今やる意味のある仕事を選びます。巡回自身で直せる小さな不具合は、その場で修復・読戻しもします。
- 詳細指示書を既存の保存先に置く。 目的、対象、必要な作業、検収方法、報告先を記録し、実際に読み返せる状態にします。配送する短文とは分離します。
- 5時間ごとの案内タスクが、準備済みの配送文を提示する。 これは案内であり、Workが勝手に起動した証拠ではありません。現状は人間がWorkへ投入する操作が残っています。
- Workが新規チャットへ一行ずつ配送する。 案件IDを付け、実際の送信結果を記録します。担当がまだ回答しなくても、配達そのものはそこで終了します。
- 担当AIが仕事をして、成果を保存する。 Aは戦略、Bは修正や制作など、Cは必要な場合だけ利用事例。担当はGitHub・文書などに成果を残し、決められたリーダー報告先へ直接報告します。
- 次の巡回が成果と未解決を回収する。 配送の証拠、担当が受け取った証拠、実物ができた証拠を別々に確認し、リーダーが次の判断に使えるようにします。
重要なのは、「送った」＝「受け取った」＝「完成した」ではないこと。荷物の追跡番号があっても、中身の組み立てが終わったとは限りません。
また、毎回大量に配ることは目的ではありません。現在のWork60はA・B合計で最大100件を候補として扱える設計ですが、これは実績数でも一回で100件走らせる約束でもありません。必要なら0件でもよいし、Cは別枠で最大1件の任意運用です。
実際には、どこまで動いたのか
ここは宣伝文句より、開発記録をそのまま見るほうが面白いところです。以下は2026年11月12日朝時点の記録に基づく整理です。
| 観点 | 確認できたところ | 残っていること |
|---|---|---|
| 仕様・指示書の管理 | GitHub・Google Driveへの保存と読戻しが複数の工程で実行済み | すべての案件の独立再現を保証する段階ではない |
| 担当への配送 | 新規チャットへの送信が個別試験で成功。現在のWork60ではAの送信成功URL提示と担当報告を確認 | 最新8件のうち残る7件は送信・受領状況がUNKNOWN。Aの元GUI送信控えも独立照合待ち |
| 担当AIの実務 | GitHub上の局所修正や文書保存・読戻しなど、実物を伴う成功例がある | 配送された8件がすべて実務完了したわけではない |
| 定期巡回 | 実際に定時実行し、既存案件の点検、修復、報告記録を実施 | 障害の再発防止と、未解決を継続的に減らす運用は改善中 |
| 全体の自動連携 | 分担する各工程の動作実績を確認 | 人間のWork起動を含めた端から端までの無人連続運転は未実証 |
最新の管理表には、未完了の親案件が12件、Work60の配送状況が不明なものが7件、期限に基づく再確認が未消込のKB項目が37件あります。ただし、これらは重なりのある別の数え方なので、合計56件の障害があるという意味ではありません。 また、再確認の期限が来た項目を、そのまま内容の誤りと数えることもできません。
「全部動いた！」と言いたいところですが、そこはぐっと我慢。今の判定は、部分的には成功、統合運用は改善中です。
一番勉強になったのは「AIにも官僚主義がある（笑）」ということ
開発を始めたころ、私は「AIなら人間の組織にありがちな面倒な手続きは減るだろう」と思っていました。ところが複数のAIをつないでみると、AIが自分で作った確認・承認・報告のルールに、AI自身が縛られる。これがなかなか見事なんです（笑）。
たとえば「仕事を進めて」と頼んでいるのに、AIの返事は「指示書は準備できました」「確認が必要です」「次工程は未実施です」。いや、だから仕事を進めてほしいんだけど！ という場面が何度もありました。
失敗① 配達係が「宛先がありません」と帰ってきた
初期のWork指示には「既存の担当チャットへ配送する」と読める部分がありました。でも、その担当チャットがどこにあるのか、Workには分かりません。配送の指示書は完璧に用意したのに、そもそも配達先が存在しない（笑）。
そこで「新しいチャットを作る→実際のURLを確認する→短い指示を送る」の順番に変更しました。人間なら何となく補ってしまう前提も、別AIへの依頼では手順として明示する必要があります。
失敗② 書類は揃った。でも、送ったかどうかは誰も分からない
今度は配送できたはずなのに、操作履歴と担当の受領記録を照合しきれない案件が発生しました。担当から成果が来ていなければ、配達できなかったのか、配達したけど作業中なのか、それすら区別できません。
ここで適当に再送すれば、同じ仕事を二重に発注する危険があります。そこでUNKNOWN（送信・受領の未確認）を独立した状態として残す方式にしました。配達控えと完成報告は別のもの。書類の種類だけ増えて、実はまだ中身が完成していない……なんとも役所っぽい話です（笑）。
失敗③ 安全確認が増殖して、仕事そのものが止まった
一番困ったのはこれです。「全部の検査がPASSするまで次へ進めない」「報告が揃うまでHOLD」。安全のためのルールだったはずなのに、一件の未確認が、無関係の作業まで止めることがありました。
人間の組織でも、書類のひとつに判子がないだけで全員が待機する、あの現象です。AIでも起きました（笑）。
今はAD&C独自の一律STOP/HOLDをやめ、実際の権限・安全条件を守ったうえで、できる部分を実行→結果を保存→問題のある部分だけ直す方式に変更しています。失敗した工程は未完了と正直に残しますが、成功した工程まで取り消しません。
失敗④ 37件「確認しました」。それで何件直ったの？
定期巡回にも落とし穴がありました。大量の案件を読んで、立派な報告書を作る。ところが読んだ件数と、改善した件数はまったく別です。
そこで、未解決の総数を分母、今回確認した数を分子として記録し、さらに「改善・実装」「解決・消込」の列を分けました。2026年11月12日朝の記録では、期限に基づく再確認が必要な37件のうち確認は1件、改善・実装は0件、解決も0件でした。
「たくさん調査しました」という報告と、「問題が減りました」という成果を混ぜない。 言われてみれば当たり前ですが、AIはもっともらしい長文の報告が得意なので、ここは意識して区別しないと危険でした。
失敗⑤ 人間に「もう一回入力してください」と言い始めた
そして地味に腹が立つのが、人間への差し戻しです。AIは文字列を補うのが得意なのに、人間に長い指示文の再入力や再承認を要求する。人間はわざわざ手のマニピュレーターを動かして、キーボードというメカを操作しているんですよ。人間の入力コストは高いんです（笑）。
だからAD&Cでは、AIが補える文面は補い、実行できる部分は実行し、人間には本当に必要な判断だけを短く求める方向にしています。これは操作画面やボタンの作り方を含む、AIインターフェイス設計そのものの問題です。
失敗⑥ 「偽ZIPツール事件」――存在しない道具が、何度でも発掘される（笑）
動画制作で音声を出力するための既存ツールがあったのですが、途中で担当AIが勘違いして、使うべき道具とは別の「ZIPツールらしきもの」を新しく作ってしまったことがありました。しかも、これは一回きりの失敗で終わりませんでした。
いったんファイルが残ると、次のAIがツールを探したとき、その偽ZIPが検索結果に出てきてしまう。AIは「見つかったのだから使うべき道具だろう」と誤解し、また同じ方向へ進む。間違ったものを作ったせいで、次のAIまで間違えるという、なかなか見事な誤情報の自家増殖です（笑）。
さらに厄介だったのが、AIは不要なファイルをなかなか消したがらないこと。「念のため残しましょう」「履歴として保存しましょう」と、丁寧な保全提案が次々と出てくる。でも、ここで必要だったのは資料を増やすことではなく、正しい音声出力ツールを一つに定め、誤った候補を検索・案内の対象から外すことでした。ファイルを残すなら履歴へ隔離し、現役の道具として発見されないようにする必要があります。
つまり、AIの検索能力を高めても、検索される道具棚に偽物が混じっていたら、間違いを高速に繰り返すだけ。消さない優しさが、次のAIには不親切になる。これもまた、AIの官僚主義らしい事件でした（笑）。
結局、AIの官僚主義をなくす方法は「ルールを全部消す」ことではありません。書類を作ることを成果にせず、実際の仕事が一歩進んだかを見ること。 私には、この失敗が一番勉強になりました。
この仕組みの本当のポイントは「AIを増やす」ことではない
私は、複数のAIが会議している画面を見たいわけではありません。人間が同じ説明を何度もしなくても、前の成果を受け取って仕事が先へ進むことが目的です。
そのために必要だったのは、意外にも派手なAI技術より地道な運用でした。
- チャットの外に、現在の仕様と決定事項を残す。
- 仕事にIDを付け、誰が何を受け持つか決める。
- 「指示した」「届いた」「作った」「確認した」を混同しない。
- 問題があれば小さく直し、既にできた成果を捨てない。
- 次回は全文を読み直すのでなく、変わったところから再開する。
同じやり方は、ブログ制作にも応用できます。記事の企画、本文、図解、WordPressへの投稿を別工程として扱い、完成物を確認する。ただし、それは今回紹介した「チャットを使った開発プラクティス」の一つの応用例です。今回の主役は、ブログ自動投稿そのものではありません。
次の実験は、tmpスケジュールによる「仕事の自動チェーン」
実はもう一つ、「そろそろ作ろうよ（笑）」と思っている仕組みがあります。一時的なスケジュールタスク（tmp）を使って、仕事を次の仕事へつなぐ構想です。
普通の予定通知だけで終わらせず、「未完了の実務を1件選ぶ → 決めた時刻に実行する → 成果を正本へ保存して確かめる → 完了していれば同じtmp枠を次の仕事へ書き換える → 次の時刻にまた実行する」というチェーンを考えています。人間が毎回「次をやって」とキーボードで命令する代わりに、AI側で次の一手をつなげられないか、という実験です。
実際にChatGPTのスケジュール機能は使えており、AD&Cには再利用用の「tmp」タスクが1枠あります。ただし、現在は無効・未割当で、自動で書き換えて次を実行する一気通貫の試験はまだできていません。スケジュール機能があることと、「自動チェーンが完成した」ことは別です。
もし実行環境で次回設定まで可能なら、一つのtmp枠で小さくループさせたい。前の結果を確認してから次の仕事に進み、未完了を上書きしない。障害があれば原因を観測し、最小修正と再実測を行い、完了すれば終了する。新しいtmpを無制限に増殖させるのではなく、定期巡回と既存の成果記録を利用する考え方です。
ただ、この構想もAIの「官僚主義」に陥ると、実務より「次回実行の承認をお願いします」が増えかねません（笑）。人間が判断すべきことは人間に、機械的な継続操作はAIに。その分担を実際に検証するのが次の課題です。
まず小さく試すなら
いきなり100件を配る必要はありません。例えば、1件の実務と1件の確認作業から始めます。保存先に短い指示書を置き、担当チャットで実行して、成果のリンクと未完了を記録する。翌日に定期タスクで差分を見直してみる。それだけでも、単なるチャットでの相談と「続けられる開発」の違いが見えてきます。
Workを使える環境なら配送にも挑戦できます。ただし、サービスの提供状況、権限、サイト側の制限によって操作できる範囲は変わります。自動起動や無人運転を前提にせず、最初は人間が結果を照合できる小さな範囲が適切です。
おわりに――完成しない仕組みで、完成する仕事を増やしたい
AD&Cの方針は、「完成形のない仕組みで、完成する仕事を増やす」です。
ChatGPT Plusでの開発も同じ。AIが一度できたことと、毎回安定してできることは違います。実際に動かしてみると、配送で止まり、報告で迷子になり、確認だけが積み上がる（笑）。でも、成功した部分を残し、原因を直し、次のチャットへ引き継げれば、少しずつ前に進めます。
今後の課題は、残っている配送UNKNOWNの照合、定期巡回による実際の修復を増やすこと、そして人間が仲介しなくても安定して回る範囲を実証すること。すでに動いた部品を、どうつなげば人間の手間が本当に減るのか。 そこが次の実験です。
「AIで何でも自動化できた」という話ではありません。AIと一緒に、失敗しても続きからやり直せる開発を作っている話です。私には、そのほうがずっと面白いと思えています。
