【実践】ChatGPTの音声だけで自宅PCのClaude Code・Codexに開発指示!GitHub Issuesを使ったAI開発環境を構築してみた

「散歩しながら、AIにプログラムを開発してもらえたら便利なのに」

そんな発想から、ChatGPTの音声会話を入口にして、自宅のWindows PCで動くClaude CodeやCodexへ開発指示を届ける環境を構築しました。

しかも、単にAIにコードを書かせるだけではありません。

GitHub Issuesに開発依頼を登録すると、自宅PCが自動で依頼を受け取り、AIが調査・実装・テストを行い、結果をGitHubに返してくれる仕組みです。

今回は、この環境の構成、実装方法、実際に動作確認できたことを紹介します。

1. そもそも何を実現したかったのか?

普段の開発では、Claude CodeやCodexを利用しています。

どちらも非常に便利ですが、基本的にはPCの前で指示を出し、結果を確認する必要があります。

そこで考えたのが、こんな開発スタイルです。

  • 散歩中にスマートフォンでChatGPTと会話する
  • 思いついた機能追加や不具合調査を音声で依頼する
  • 自宅PCでClaude CodeやCodexが作業する
  • 調査・実装結果をGitHubに記録する
  • 帰宅後に成果物を確認する

つまり、人間は開発内容を考えることに集中し、実際の作業はローカルのAIエージェントに任せるというスタイルです。

2. システム全体の構成

今回採用したのは、GitHub Issuesを指示の受け渡し場所として利用する構成です。

スマートフォン
  │
  ▼
ChatGPT(音声会話)
  │
  │ 開発依頼を登録
  ▼
GitHub Issues
  │
  │ 定期的に確認
  ▼
自宅Windows PC
  │
  ▼
ローカルBridge(PowerShell)
  │
  ├── Claude Code
  │     └── 調査・分析・設計
  │
  └── Codex
        └── 実装・修正・テスト
  │
  ▼
GitHub Issuesへ結果を投稿

この構成のポイントは、ChatGPTが自宅PCへ直接接続する必要がないことです。

自宅PC側のBridgeがGitHubを定期的に確認し、新しい依頼を取得します。

そのため、外部から自宅PCへ接続するためのポート開放やWebhook受信用サーバーを用意する必要がありません。

3. なぜGitHub Issuesを使ったのか?

最初はChatGPTから直接ローカルPCのAIを操作する方法も考えました。

しかし、外出先から自宅PCへ直接アクセスする仕組みを構築すると、ネットワーク設定や認証、セキュリティ管理が複雑になります。

そこで、すでに開発で利用しているGitHubを中継地点にしました。

GitHub Issuesなら、開発依頼の内容、作業状況、AIからの回答を一か所に残せます。

また、GitHub APIを利用できるため、PowerShellやGitHub CLIとの相性も良好です。

今回の構成では、Bridgeが定期的にIssueを確認するポーリング方式を採用しています。

4. ローカルBridgeをPowerShellで構築

BridgeはWindows上で動作するPowerShellスクリプトです。

主な役割は、GitHub Issuesから依頼を取得し、適切なAIエージェントに渡し、結果をGitHubへ返すことです。

今回の環境では、以下の技術を利用しています。

技術役割
ChatGPT Voice音声による開発指示
GitHub Issues指示・結果の管理
GitHub CLI(gh)Issueの取得・操作
PowerShellローカルBridge
Claude Code調査・分析・設計
Codexコード実装・テスト
GitHub AppBridgeからのGitHub操作の認証

Bridgeは約30秒間隔でGitHubを確認する方式で検証しました。

Issueの処理状態はラベルで管理しています。

  • claude:processing:処理中
  • claude:done:完了
  • claude:error:エラー

これにより、処理中の依頼を区別したり、完了した依頼を管理したりできます。

5. Claude CodeとCodexを使い分ける

今回の環境では、Claude CodeとCodexの両方を利用できるようにしています。

例えば、Claude Codeには既存システムの調査や分析、設計を担当させ、Codexには具体的なコード変更やテストを担当させます。

開発依頼に応じて、適切なエージェントへ処理を振り分ける仕組みです。

これまでのように人間がターミナルを開き、毎回プロンプトをコピーして貼り付ける必要を減らせます。

また、調査結果や実装結果をIssueに残せるため、後から作業内容を確認しやすい点もメリットです。

6. 実際に動作確認してみた

構築しただけではなく、実際の開発プロジェクトを使って動作確認も行いました。

Claude Codeによる調査

GitHub Issueへ調査依頼を登録すると、ローカルBridgeが取得し、Claude Codeへ処理を渡すことに成功しました。

Claude Codeはローカルのプロジェクトを調査し、その結果がGitHub Issueのコメントとして返されました。

つまり、Issue登録からローカル調査、結果の返却までの一連の流れが動作しています。

Codexによる実装

Codex側でも、GitHub Issueを起点とした開発処理を確認しました。

実際にローカルファイルの修正、テスト実行、結果のGitHubへの投稿まで成功しています。

RINQプロジェクトのIssue #27では、ローカル変更と3件のテスト成功を確認できました。

単なるチャット応答ではなく、実際の開発作業を処理できたことが大きな成果です。

なお、音声入力から全工程を無人で継続運用する部分については、各エージェントの実行権限や常駐動作を含め、運用条件の確認が必要です。

7. セキュリティ面で工夫したこと

この仕組みでは、AIがローカルのソースコードへアクセスするため、セキュリティ対策も重要になります。

今回の構成では、GitHub Appを使った認証や、対象リポジトリのアクセス権限を利用しています。

また、外部からローカルPCへ直接接続させるのではなく、PC側からGitHubへアクセスする方式にしました。

さらに、調査のみの依頼と、ファイル変更を伴う実装依頼を区別できるようにしています。

特に本番環境を持つプロジェクトでは、開発コードの変更と本番デプロイを別の操作として管理することが重要です。

AIに作業を任せる場合でも、何を変更してよいか、どこまで実行してよいかという境界は明確にしておく必要があります。

8. 実際に使って感じたメリット

今回の仕組みで特に大きいと感じたのは、開発指示を出す場所がPCの前に限定されなくなることです。

例えば、散歩中に新しい機能を思いついた場合でも、スマートフォンでChatGPTと相談し、その内容を開発タスクにできます。

そして自宅PCでは、Claude CodeやCodexがローカルの開発環境を使って作業できます。

もう一つのメリットは、GitHub Issueが作業履歴として残ることです。

何を依頼したのか、AIが何を実行したのか、どのような結果だったのかを後から確認できます。

複数のAIエージェントを利用する場合でも、GitHubを中心に管理できるのは便利です。

9. 今後やってみたいこと

今後は、この環境をさらに発展させたいと考えています。

例えば、調査から設計、実装、テストまでの連携をよりスムーズにしたり、外出先から進捗を確認しやすくしたりすることです。

また、複数の開発プロジェクトを扱えるようにすれば、日常的な開発作業の進め方そのものが変わる可能性があります。

もちろん、すべてをAIに任せればよいわけではありません。

重要な仕様の判断や本番環境への反映については、人間が管理する仕組みも必要です。

10. まとめ

今回、ChatGPTの音声会話、GitHub Issues、PowerShell、Claude Code、Codexを組み合わせたローカルAI開発環境を構築しました。

特に重要なのは、ChatGPTを開発指示の窓口にし、GitHubを介してローカルのAIエージェントに仕事を渡せるようにしたことです。

これまではPCの前に座ってAIへ指示していましたが、今後は散歩中や外出先でも開発内容を考え、タスクを依頼するスタイルへ移行できます。

AIがプログラムを書く時代から、AI同士を連携させ、人間が開発全体を指揮する時代へ。

今回の仕組みは、そのための第一歩になりそうです。


タグ候補: ChatGPT、ChatGPT Voice、Claude Code、Codex、GitHub Issues、PowerShell、AIエージェント、AI駆動開発、Windows、開発自動化

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です