GitHubへの送信前にAIの更新作業が止まった――承認と再開の手順を考える
樋門AIエージェントの共有内容を更新する際、GitHubへの送信前にCodex側の自動審査で作業が止まりました。変更提案と共通版への反映で承認した範囲、社員の環境ではまだ試していないこと、再開に必要な記録を整理します。
樋門AIエージェントを社員と使い、実務で見つかった不足を共通の知識や手順へ戻す取り組みを進めています。そのために、ファイルと変更履歴を共有できるGitHubを使っています。
以前の記事では、社員がAIと仕事をして得た経験を、会社の共通の知識や手順へ戻したいと書きました。私が先に試している使い方も多く、社員全員が同じ範囲の仕事をAIへ任せられる状態には、まだなっていません。それでも、社員自身の気づきや作った道具も、他の社員が使える形へ戻していきたいと考えています。
今回は、その更新を進める途中で、承認の仕組みにより作業が止まった話です。作業を依頼していたのは、開発やファイルの編集を支援するAIエージェントのCodexです。こちらが更新を許可しても、GitHubへ送信する前に処理が止まりました。止めたのはGitHubではなく、Codexが動いている作業環境側の自動審査でした。
最終的に反映できた更新もあります。しかし、許可したら必ずそのまま進むという理解では、実際の動きと合いませんでした。社員からも改善を戻せるようにするには、止まった理由を理解し、再開できる手順まで必要なのだと感じました。
GitHubに拒否されたのか、送信前に止まったのか
画面上で作業が止まると、GitHubへ接続できないのか、アカウントに書き込み権限がないのか、更新内容に問題があるのか、すぐには分かりません。ただ、原因によって確認する場所は変わります。
今回の停止は、GitHubへ更新を送り、GitHub側から拒否されたというものではありません。AIが送信の操作をしようとしたところで、作業環境側の承認の仕組みにより、その操作が実行前に止められました。
ここを混同すると、GitHubの設定だけを直そうとしたり、権限を広げればよいと考えたりしてしまいます。しかし、送信する前の段階で止まっているなら、まず、何の操作が審査され、どのような理由で止められたかを見る必要があります。
「GitHubの更新ができない」という一言で扱わず、手元の変更、送信、共通版への反映が、それぞれどこまで進んだかを確認する。 この整理が、作業を再開する前に必要でした。
以前の樋門エージェントの記事では、社員が使ったことで共有内容の説明不足が見つかった話を書きました。今回は、その説明や手順を共通版へ戻す途中で見つかった課題です。内容を直す作業と、それを共有する場所へ届ける作業の間にも、確認が必要な場面がありました。
作業するAIとは別に、操作を審査するAIがいる
この仕組みは、読者には少し分かりにくいかもしれません。大づかみに言えば、作業するAIが「この操作を実行したい」と申請し、承認が必要な操作の一部を、別の審査用AIが確認する形です。
2026年10月時点のOpenAIのAuto-reviewの公式説明でも、対象となる承認要求を別の審査エージェントへ回す仕組みとされています。すでに作業環境で許されている通常の操作には、この追加審査が入らない場合があります。審査する役割が変わっても、ファイルや通信に関する権限そのものが広がるわけではありません。
今回のように、作業場所の中でファイルを直すことと、その内容を外部の保存先へ送ることでは、影響する範囲が違います。利用者にとっては一続きの「更新」でも、実行する側では別の確認が必要になる場面があります。私の許可も、作業環境の制約を無条件に解除するものではありません。
ただし、今回の審査が内部でどの情報をどの順番に評価したのか、なぜその結論になったのかを、実装まで追って確認したわけではありません。ここで説明しているのは、確認できた停止の位置と、公式資料で示されている仕組みです。内部の判断を推測して断定しないようにしたいと思います。
送信の承認と、共通版への反映を分ける
今回の配筋関係の更新では、停止した後に送信先を明示して承認し、GitHub上に変更提案であるプルリクエストを作成できました。その後、共通版として扱うmainへ取り込むことについて、別に許可を出し、反映まで進めました。mainは、このリポジトリで共通版を管理しているブランチ、つまり変更履歴の系列の名前です。
数量に関する別の更新でも、台帳を含む送信が一度止まり、その後の許可を経てmainへ反映できました。一方、社員向けの案内資料は、この記事で扱う時点では、まだGitHubへ送信していません。更新対象ごとに進み方と到達した段階が違うため、全部をまとめて「反映済み」とは扱えません。
この経緯で、承認する内容も分けて考える必要があると感じました。手元で編集してよいという許可、指定した保存先へ送ってよいという許可、変更提案を作ってよいという許可、共通版へ取り込んでよいという許可は、それぞれ対象が異なります。
今回の運用では、変更案を送信できた時点で、全員が使う版への採用まで認めたことにはせず、プルリクエストの作成とmainへの反映を、別の承認として進めました。すべての環境で毎回同じ承認の分け方が必要だと確認したわけではありません。
また、一度具体的に承認して進んだ事例があっても、同じ言い方なら今後の操作が必ず通るということではありません。送る内容や送信先、操作の影響が変われば、確認すべき範囲も変わります。拒否された操作を別の方法で押し通すための手順として、今回の経験を扱うつもりもありません。
安全確認を残しながら、仕事を止めたままにしない
会社の資料を扱う以上、外部へ送る前に確認が入ることには意味があります。自分の意図とは違う資料まで含まれていないか、送信先が合っているか、更新の範囲が広がっていないか。確認しないまま進めることはできません。
一方で、通常の業務を進めるたびに、何が足りなくて止まったのか分からない状態では、実務に組み込みにくくなります。AIへ依頼した後、人が毎回その場で仕組みを調べ直す運用では、社員にも渡しにくいと思います。
まずは、送ってよい情報と送信先、実行してよい操作を整理し、必要な承認を具体的に示せるようにしたいと考えています。制限を広く外すことから始めるより、実際の作業範囲を確かめたいのです。
社員向けの案内にも、「更新してよい」とだけ書くのではなく、対象のファイル、送信先のリポジトリとブランチ、どこまで実行するか、今回含めないものを示す必要があります。リポジトリは、共有するファイルと変更履歴をまとめて管理する場所です。こうした情報は、審査を通すための決まり文句ではなく、人もAIも同じ作業範囲を確認するためのものです。
また、自動審査で操作が認められたことと、変更内容が技術的に妥当であることは、別に確認します。配筋や数量の扱いを共通版へ戻す際には、今回の条件に対する根拠や、他の案件でも使える範囲を人が確かめる必要があります。
社員から戻る改善を次の仕事で使えるようにするには、更新を送るところまで進められることと、採用する内容を人が確認できることの両方が必要だと感じました。
社員の環境でも同じように動くかは、まだ分からない
ここまでの経験は、私が使った作業環境で起きたことです。社員側の環境で、同じ操作が同じ理由で止まるかは、まだ検証していません。
OpenAIの権限モードの公式説明でも、利用できる承認モードは、アプリの版や実行環境、設定、組織の要件によって変わるとされています。私の環境で通った手順を、そのまま全社員に共通するものとして扱うのは早いと思います。
社員に試してもらう際には、対象を絞って、どこまで進み、どの段階で確認が必要になるかを見たいと考えています。止まった場合は、許可を繰り返すだけでなく、実行しようとした操作と表示された理由を残し、人へ確認を戻せるようにしておく必要があります。
そのとき大事なのは、途中まで進んだ仕事を失わないことです。変更内容は手元に残っているのか、送信は済んでいるのか、承認を待っているのはどの操作なのか。再開する人が判断できる記録まで含めて、運用を整えたいと思います。
この経験は、同じようにAIへ更新作業を任せる会社でも、作業が止まったときの確認の手掛かりになるかもしれません。接続先の問題なのか、その前の操作が許されていないのか。更新のどこまでが済んでいるのか。そこを分けて見ると、確認する相手や、再開に必要な情報を整理しやすくなります。
今回、実際に更新が止まったことで、共有する知識やコードだけでなく、承認と再開の手順まで整える必要が見えてきました。安全確認の役割を保ちながら、社員が状況を理解して仕事を続けられる形にできるか。まだ途中ですが、実際の動きを確かめながら整えていきたいと思います。