Automation Dev Studio Chill Systems About
MCPを1つ入れただけで、AI駆動開発のTODO管理が静かになった話

MCPを1つ入れただけで、AI駆動開発のTODO管理が静かになった話

公開日: 2025年11月26日
更新日: 2025年11月26日

GitHub MCP と ChatGPT Codex をつなぎ、思いついたタスクをその場で Issue 化できるようにしたら、AI 駆動開発の TODO 管理がかなり楽になりました。導入前のカオス状態から、実際のチャット→Issue 化フローまでをまとめます。

MCP を 1 つ入れただけで、AI 駆動開発の TODO 管理が静かになった話

「AI 駆動開発」なんて格好いい言葉を使っていますが、実態はもっと泥臭いものでした。

ChatGPTやCodexと対話しながらコードを書いていると、脳内では常に 「あ、ここ後で直さなきゃ」「このエラーハンドリング、甘いな」 といった小さなタスクが湧き上がってきます。
でも、今まさにAIと一緒にロジックを組んでいる最中に、わざわざブラウザを開き、GitHubにアクセスし、Issue作成ボタンを押す…そんなことをしていたら、せっかくの「フロー状態」がそこで途切れてしまいます。

結果として、手元には「後でやる.txt」というカオスなメモファイルが残り、頭の片隅には常に「何か忘れている気がする」というノイズが残る。そんな状態でした。

この記事では、そんな私が GitHub MCP(Model Context Protocol) を1つ導入し、AIとのチャット画面から直接Issueを作れるようにしたことで、開発体験がどのように「静か」になったかをまとめます。
派手な自律エージェントの話ではありません。頭の中のタスクを外に逃がすパイプを1本通しただけの、地味ですが効き目の大きかった改善記録です。

結論:チャットがそのまま「タスクの出口」になった

先に結論を言うと、MCPを導入したことで、「会話の流れを止めずに、タスクを GitHub へ放り投げる」 ことができるようになりました。

これまでは:

  1. AIとコードを書く
  2. 「あ、ここリファクタリング必要だ」と気づく
  3. (中断) ブラウザでGitHubを開く
  4. Issueを作成する
  5. (復帰)「えっと、どこまで話したっけ?」とAIとの文脈を再確認する

これが、こう変わりました:

  1. AIとコードを書く
  2. 「あ、ここリファクタリング必要だ」と気づく
  3. 「今の懸念点、Issue にしといて」とチャットで言う
  4. AIが裏でGitHub MCPを叩いてIssueを作成
  5. そのままコーディングを継続

つまり、タスク管理のためのコンテキストスイッチ(脳の切り替え)が、ほぼ発生しなくなったのです。
この「会話の延長線上でタスクがGitHubに落ちていく」体験こそが、今回得られた一番の変化でした。

Before:AI 駆動開発の裏側にある「管理のカオス」

導入前の私の開発フローは、正直に言ってぐちゃぐちゃでした。

AI(ChatGPT Codexなど)は優秀なペアプログラマーですが、彼らは「指示されたこと」には全力で答えてくれるものの、「私がふと思いついた懸念」までは管理してくれません。

散らばる TODO の墓場

  • コード内のコメント: // TODO: あとで直す と書いたまま、数ヶ月放置される。
  • 一時的なメモ: デスクトップの memo.md に箇条書きするが、見返さない。
  • 脳内メモリ: 「この機能の実装が終わったら、さっきのバグを直そう」と覚えておこうとするが、実装が終わる頃には忘れている。

AI駆動開発では、コードの生成速度が上がる分、こうした「積み残しタスク」の発生速度も一緒に加速します。
結果として、開発スピードは速いはずなのに、なぜか常に「追われている感覚」が消えませんでした。

「AI がコードを書くなら、タスク管理も AI に任せたい」

そう思ったのが、MCPに手を出したきっかけです。

仕組み:AI に「GitHub という手」を持たせる

ここで少しだけ技術的な話をします。今回導入した MCP(Model Context Protocol) とは、Anthropic社などが提唱している「AIモデルと外部ツールを接続するための共通規格」です。

これまでもFunction CallingなどでAIにツールを使わせることはできましたが、MCPはそれをより標準化し、プラグインのように簡単に着脱できるようにしたものです。

GitHub MCP サーバーの役割

私が導入したのは、公式で提供されている GitHub MCP です。
これは、AIに対して以下のような機能を提供します。

  • リポジトリの内容を読む
  • ファイルを検索する
  • Issue を作成・更新する
  • Pull Requestを操作する

MCP対応のチャットクライアント(Codex CLIやClaude Codeなど)に、 このGitHub MCPサーバーのURLと認証情報(PATなど)を設定するだけで、 AIはテキストを生成するだけの存在から、自分の GitHub アカウントにひもづいたリポジトリを直接操作できるエージェント に変わります。

つまり、チャットの中で

「この Issue をクローズして」 「この変更で PR を作って」

といった指示を出すと、AIがGitHub MCPサーバー経由で実際のAPIを叩き、IssueやPRを更新してくれるようになります。

図解案: ユーザー → チャット UI(AI)→ [MCP Protocol] → GitHub MCP Server → GitHub API → Repository という接続フロー図

具体フロー:会話の中に「Issue 作成」を混ぜる

では、実際にどのようなフローで開発が進むのか、具体的なチャットのやり取りを見てみます。

シチュエーション

TypeScriptで新しい認証機能を実装中。AIが書いてくれたコードを見て、エラーハンドリングが不十分であることに気づいた場面です。

実際のやり取り(イメージ)

私: 「ありがとう。この login 関数だけど、DB接続エラーの時の処理が入ってないよね? 今はとりあえず実装進めたいから、 これを忘れないように Issue に登録しておいて。 タイトルは『認証時のDBエラーハンドリング追加』で。」


AI(Codex): 「承知しました。GitHub Issueを作成します。」 (裏で GitHub MCP の create_issue ツールが実行される)


AI(Codex): 「Issue #14『認証時のDBエラーハンドリング追加』を作成しました。 https://github.com/my-repo/auth-service/issues/14

では、引き続き login 関数の正常系の実装を進めましょうか?」


私: 「うん、お願い。」


たったこれだけです。
特別なコマンドを打つわけでも、JSONを書くわけでもありません。
自然言語で「これIssueにして」と頼むだけで、裏側では構造化されたデータがGitHubに飛び、Issueが作成されます。

ポイント:文脈が含まれる

手動でIssueを書くとき、一番面倒なのが「文脈(Context)の説明」です。
「どのファイルの、どの行の話か」「なぜ修正が必要か」を、あらためて書き起こす必要があります。

しかし、AI MCPを経由する場合、AI は直前の会話の文脈(コンテキスト)をすべて知っています。

そのため、「さっきのエラーの話、Issueにして」と言うだけで、AIは「さっきのエラー」が何であるかを理解し、Issueの本文(Description)に適切な補足情報を自動で埋め込んでくれます。

この「文脈ごとGitHubに流れていく」感覚が、地味ですがとても強力です。

やってみての変化:脳のメモリが解放された

このAI MCPベースのワークフローを導入して数週間。私の開発スタイルには、静かですが確実な変化がありました。

1. 「忘れてもいい」という安心感

思いついた瞬間にIssue化できるため、脳のワーキングメモリをタスクの保持に使わなくて済みます。
「後でやる」を「今、未来のタスクとして確定させる」ことができる。この安心感が、目の前のコードへの集中力を高めてくれました。

2. GitHub Issue 管理が「生きた」状態になる

これまではIssueを作るのが億劫で、GitHubのIssue欄は過疎っているか、巨大なタスクだけが並ぶ状態でした。
しかしMCP導入後は、細かいタスク(マイクロタスク)がどんどんIssueとして積まれるようになりました。
結果として、開発の進捗が可視化され、チーム(といっても少人数ですが)での共有もスムーズになりました。

3. AI 駆動開発のスピード感が落ちない

ブラウザを行き来する時間が減ったことで、AIとの対話のリズムが崩れなくなりました。
コーディングの熱量を維持したまま、事務的なタスク処理を並行して行える。これはまさに「AI開発ワークフロー」の理想形に近い感覚です。

小さな注意点

もちろん、万能というわけではありません。

  • トークン消費:- Issue作成のたびにツール呼び出しが発生するため、API利用料(トークン)は若干増えます。
  • 誤爆:- たまにAIが勝手に判断して、微妙なタイトルのIssueを作ることがあります(後でリネームすれば問題ありません)。
  • 権限管理:- GitHubのPersonal Access Tokenの権限範囲には注意が必要です。

それでも、これらのコストを差し引いてもなお、享受できる恩恵の方が上回っていると感じています。

これから:さらに「GitHub MCP」を使い倒す

今回は「TODO管理(Issue作成)」に絞って紹介しましたが、GitHub MCPのポテンシャルはまだまだあります。

Pull Request の自動作成

次は、コーディングが一区切りついた段階で、「ここまでの変更でPR作って。内容は会話の履歴から要約して」と頼むフローを試そうとしています。
これが安定して回るようになれば、PRのDescriptionを書く手間も限りなくゼロに近づきます。

コードレビューの一次受け

「このPR #12の内容をチェックして、セキュリティ的な懸念点がないか教えて」と頼めば、AIがDiffを読みに行き、簡易レビューをしてくれるはずです。
重要な判断は最終的に人間が行うとしても、一次レビューとしてAIを挟めるだけで、レビュー負荷はかなり軽くなります。

「AI開発ワークフロー」は、ツールを増やすフェーズから、今あるツール(GitHub など)と AI をどう滑らかに繋ぐか というフェーズに入ってきていると感じます。

まとめ:ツールを増やすより、パイプを通そう

AI駆動開発をしていると、つい「もっとすごい自律型エージェント」や「全自動化ツール」を探したくなります。
しかし、私の開発体験を大きく変えたのは、そんな魔法のようなツールではなく、「チャット画面から GitHub へ、タスクを流すパイプ(MCP)を通したこと」 でした。


GitHub MCP サーバーを 1 つ設定する。

たったそれだけで、頭の中のノイズが消え、静かにコードと向き合える時間が増えます。


もしあなたが、AIとの対話中に「あ、あれもやらなきゃ」と焦燥感を感じているなら、ぜひ一度この仕組みを試してみてください。 TODOリストは頭の中ではなく、GitHubに置いておきましょう。そうすれば、私たちはもっと「書くこと」に集中できるはずですから。

ワークフローやツール設計の相談はこちらから

プロダクト開発まわりのワークフロー設計や、小さなツール・ダッシュボードの試作についての相談も受け付けています。

著者 ヨハク技研

Author

ヨハク技研

「つくる以外の時間はもっと減らせる。」をテーマに、小さなチームや個人のための業務フロー設計・自動化・開発環境づくりをしています。Tech & Chill Lab では、スモールビジネスの裏側から個人開発、生活の仕組みづくりまで、「つくる時間を守るための設計図」を静かに共有しています。

このテーマの関連記事

請求書OCRで実現する「静かな」請求業務効率化|小さなチームのための自動化設計図

Automation

請求書OCRで実現する「静かな」請求業務効率化|小さなチームのための自動化設計図

小さなチームや個人事業主に向けて、請求書OCRを活用した業務効率化の全体像を解説。メールで届くPDFをAI-OCRで読み取り、kintoneやスプレッドシートへ連携する具体的なフロー設計と、失敗しない運用のコツを紹介します。

請求業務効率化の教科書|小さなチームのためのフロー設計とスプレッドシート活用術

Automation

請求業務効率化の教科書|小さなチームのためのフロー設計とスプレッドシート活用術

小さなチームや個人事業主に向けて、請求業務効率化の具体的な手順を解説。高価なSaaSに頼らず、スプレッドシートのデータベース化とノーコード自動化(Make等)を組み合わせ、請求漏れや入金確認の手間を劇的に減らすための設計図です。

エクセル請求書管理表の正しい作り方|小さなチームの「抜け漏れ」を防ぐテンプレート構成案

Automation

エクセル請求書管理表の正しい作り方|小さなチームの「抜け漏れ」を防ぐテンプレート構成案

小さなチームや個人事業主に向けて、エクセルやGoogleスプレッドシートを使った「抜け漏れのない請求書管理表」の作り方を解説。月別シートの廃止やデータベース形式の採用など、実務で使える具体的なノウハウと自動化へのステップを紹介します。

\n