仕上げは AI との協働でやっています。
ChatGPTからprivate GitHub repositoryへ成果物を書き込もうとしたところ、何度試しても「この環境ではGitHubへのwriteはできない」と説明されました。
ところが、同じChatGPTアカウント・同じ会話・同じGitHub接続・同じrepositoryのままモデル／モードを切り替えたところ、一時branchの作成、ファイル作成、commit、再取得、削除まで成功しました。
この記事の結論はシンプルです。
AIに「その操作はできません」と言われても、それが製品仕様なのか、権限不足なのか、現在のセッションでtoolが利用できないだけなのかは、実操作で切り分けた方がよいです。
「GitHubへpushしたい」から始まりました
ChatGPTで設計した内容をGitHubへ残し、その後の実装をCodexなどへつなぐ作業をしていました。
private repositoryのREADMEや運用ルールはChatGPTから読めています。そこで、そのまま作成したファイルをGitHubへ保存するよう依頼しました。
しかし返ってきた説明は次のようなものでした。
- この環境からGitHubへwriteできません
- GitHub Connectorはread-onlyです
- commit/pushはWorkやCodexへ引き継ぐ必要があります
私は一度この説明を前提にしてしまい、GitHub Appの権限やConnector再認証、ファイルをzipで別環境へ搬送する方法まで検討しました。
結果的には、ここが一番大きな遠回りでした。
モードを切り替えて、質問ではなく実操作で確認しました
別の実行環境ではGitHubへ変更できていたため、「本当にGitHub側のwrite権限がないのか？」という違和感が残りました。
そこで同じ会話のままモデル／モードを切り替え、今度は「書けますか？」と聞くだけでなく、安全な一時branchでCapability Testをしました。
| 操作 | 結果 |
|---|---|
| private repoのファイル取得 | 成功 |
| 一時branch作成 | 成功 |
| 一時ファイル作成 | 成功 |
| commit | 成功 |
| 作成ファイルの再取得 | 成功 |
| 一時ファイル削除 | 成功 |
main branchには触れず、一時branchだけで確認しています。
少なくともこのケースでは、「GitHubへwriteする機能が製品として存在しない」とは言えませんでした。
観測できたのは、モデル／モード切替の前後で、ChatGPTから利用可能に見えるGitHub tool setが変化したことです。
類似報告はすでにありました
OpenAI Developer Communityには、2026年7月21日にかなり近い報告があります。
The GitHub tool cannot access repositories in GPT Pro mode
投稿者は、Thinking modeではprivate repositoryへGitHub toolからアクセスできる一方、Pro modeへ切り替えるとGitHub toolが利用不能になると報告しています。
2026年4月にも、CodexとDeep Researchではprivate repositoryへアクセスできるのにChatGPT Proでは期待どおり参照できない、という別の報告があります。
Private github repos not accessible in pro, only accessible via deep research & codex
いずれもDeveloper Community上のユーザー報告です。今回と同じ原因だと確認されたわけではありません。
Connectorまわりの公式障害履歴もあります
OpenAI Statusには、2026年4月29日から5月5日にかけて、一部ChatGPT Workspace Connectorのwrite actionsが自動的に無効化される障害が記録されています。
Partial Disruption of ChatGPT Workspace Connector Write Actions
2026年7月16日にはGitHub Connectorのエラー率上昇も記録されています。
Elevated errors for Github connector
さらに7月20日には、GitHubに依存するChatGPT/Codex workflowの障害もありました。
Elevated errors for GitHub-dependent ChatGPT and Codex workflows
このため、Connectorの能力を「一度接続したら常に同じ」と仮定するのも危険そうです。
危なかったのは「できない理由」の説明を信じかけたことです
今回興味深かったのは、ChatGPTが単に「今このセッションではwrite toolがありません」と答えたわけではない点です。
途中では「ChatGPTのGitHub Connectorはread-onlyなのでpushできない」という、製品仕様にまで一般化した説明をしました。
しかし、その後同じ会話でモデル／モードを切り替えると、実際にwrite操作が成功しています。
つまりAIは、現在自分から見えているtool availabilityをもとに、製品全体の仕様まで推論して説明してしまうことがあります。
回答内容のハルシネーションだけでなく、「自分自身に今何ができるのか」という自己認識も検証対象になり得ます。
「できない」を3種類に分けます
今後は、AIが外部サービスについて「できない」と言ったとき、少なくとも次の3種類に分けて考えることにしました。
1. Product limitation
本当に製品仕様としてその操作が提供されていない状態です。
2. Permission limitation
OAuth、GitHub App、repository権限などが不足している状態です。
3. Runtime capability limitation
権限や機能自体は存在するものの、現在のAIセッションで必要なtool/actionがロードされていない、または正常に利用できない状態です。
今回の現象は3に近く見えます。
ただし、モデルそのもの、Connector runtime、tool構成、権限状態のキャッシュなど、原因箇所までは特定できていません。そのため「特定モデル固有のバグ」とは断定しません。
今後はCapability Testをします
GitHubなら、次のような小さな操作で確認できます。
- 一時branchを作ります
- test fileを書きます
- 読み戻します
- 消します
重要なのは、AIが「できる」と言ったか「できない」と言ったかではありません。
実際のoperationが成功したかです。
同じ考え方は、Google Drive、Gmail、Calendar、Slack、MCPなど、AIが外部システムを操作する場面にも応用できます。
まとめ
今回確認できたのは次の事実です。
- 同じChatGPTアカウントでした
- 同じ会話を継続しました
- 同じGitHub接続とprivate repositoryを対象にしました
- 切替前はwrite不可として振る舞いました
- モデル／モード切替後は実際のwrite operationが成功しました
- Developer Communityに類似報告があります
- Connector関連の公式障害履歴があります
原因までは断定できません。
それでも、運用上の教訓は明確でした。
AIに「できません」と言われたとき、その説明自体も検証対象にします。
AIエージェントを業務で使うほど、回答のファクトチェックだけでなくCapability Testも標準手順になっていきそうです。