api.github.comに繋がらないClaude.aiで、GitHubエコシステムを自律運用する

1. 壁に気づく

あるAIチャットサービスのコンテキストでGitHubのAPIを直接叩こうとした瞬間に、それは起きた。接続が通らない。ネットワーク制限がある。api.github.comへのアクセスがブロックされている。

最初は「できないこと」として処理した。しかしすぐに別の問いが浮かんだ。「github.com（gitプロトコル）はどうか？」と。試してみると、通った。git cloneも、git pushも、問題なく動く。

この非対称性——APIは通らないがgitは通る——が、以降の設計をすべて決めた。

2. 非対称性を地図にする

整理すると、利用できるものと利用できないものが明確になった。

✅ 通るもの：github.com（git clone / git push / git pull）
❌ 通らないもの：api.github.com（REST API / GraphQL / Projects API）

GitHub Projects APIを直接叩けなければ、タスク管理も自動化できない。一見すると詰んでいる。しかし視点を変えると、別の経路が見える。GitHubには、リポジトリへのpushをトリガーにして任意のスクリプトを走らせる仕組みが存在する。GitHub Actionsだ。そして、ActionsはAPIを叩ける。

AIチャット → git push → Actions起動 → API呼び出し → privateリポジトリへ書き戻し → AIチャット → git pull

APIに直接アクセスできないなら、APIを叩ける別のシステムに橋渡しをすればいい。publicリポジトリがその橋になる。

3. アーキテクチャの全体像

システムは二つのリポジトリで構成される。publicリポジトリ（エンジン）とprivateリポジトリ（記憶）だ。

publicリポジトリ（エンジン）
・GitHub Actionsのワークフロー定義
・AIチャットが書き込むagent/request.json
・pushをトリガーに動くブリッジ

privateリポジトリ（記憶）
・日次ログ・プロジェクトキャッシュ・スキル定義
・Actionsが書き込み、AIチャットがpullして読む
・外部からは見えない個人の脳

AIチャットが何かをしたいとき、まずagent/request.jsonにアクションの指示をJSONで書く。そのファイルをpushした瞬間、Actionsが起動する。ActionsはAPIを叩き、結果をprivateリポジトリへ書き戻す。AIチャットがpullすれば、結果が手元に届く。

APIへの直接アクセスは一度も起きていない。しかしその恩恵はすべて受けている。

4. リクエストとレスポンスの設計

AIチャットが書くリクエストは、シンプルなJSONだ。

{"action": "fetch_project", "payload": {}}

{"action": "update_task", "payload": {"updates": [{"task_id": "xxx", "new_status": "Done"}]}}

{"action": "write_memory", "payload": {"path": "daily/2026-03-26.md", "content": "..."}}

Actionsのワークフローはこのauthority（action）フィールドを読んで処理を分岐させる。プロジェクトのタスク取得・ステータス変更・ファイル書き込み・Issueの作成——それぞれのアクションがAPIを経由して実行される。

pushを確実にトリガーするため、request.jsonにはタイムスタンプフィールドを自動付与する。内容が同じでも毎回差分が生まれるので、Actionsは必ず起動する。

5. publicとprivateが果たす役割分担

この設計の面白さは、publicとprivateを使い分ける理由がコスト以外にもあることだ。

GitHub Actionsは、publicリポジトリなら無制限・無料で動く。privateリポジトリには月あたりの上限がある。だからエンジンはpublicに置く。逆に記憶——日次ログ、プロジェクトの状況、個人のスキル定義——は外部に見せたくない。だからprivateに置く。

コスト最適化とプライバシー保護が、同じ設計判断から同時に解決される。制約から生まれた構造が、意図せず理想的な役割分担を実現していた。

6. 非同期であることの強さ

このアーキテクチャは非同期だ。AIチャットがpushして、Actionsが処理して、結果をpullする。リアルタイムではない。

しかしこれは弱点ではない。日常業務の大半は、数十秒の待機を許容できる。タスクの更新、ログの保存、プロジェクトの状況確認——これらはリアルタイムである必要がない。必要なのは確実性と継続性だ。

非同期だからこそ、AIチャットのセッションが終わっても処理は続く。ネットワークが不安定でも、pushさえ通れば後はActionsが完走する。障害ポイントが少なく、回復も自動だ。

7. 記憶が蓄積するシステム

このシステムで最も価値があるのは、記憶が外部化されることだ。AIチャットはセッションをまたいで記憶を持てない。しかしprivateリポジトリにgit pullすれば、過去のすべての文脈を読み込める。

セッション開始時に日次ログとプロジェクトキャッシュを読む。これだけで、前回の会話の続きから始められる。記憶はAIの内側ではなく、Gitの外側に積み上がっていく。使えば使うほど文脈が豊かになる。道具ではなくインフラとして育っていく。

道具は消耗する。インフラは育つ。

8. 制約が問いを立て、問いが設計を生む

「できない」という事実は、問いの起点だ。できない理由を調べると、何が通って何が通らないかが分かる。その境界線を精密に把握した瞬間に、設計の余地が生まれる。

APIが通らないなら、gitを通す。gitしか通らないなら、gitをトリガーにする。トリガーにできるなら、その先でAPIを叩く。一つ一つの問いが次の問いを引き出し、迂回路が主道に変わっていく。

制約を「壁」として見ると、諦める理由になる。「地形」として見ると、設計の素材になる。今回の発見は技術的な工夫というより、視点の転換だったと思っている。