自動化処理 9 本を CLI 直接起動に完全移行した——パーミッション層の壁をどう越えたか
2026-05-01
🎯 結論
先週、社内の自動化処理 9 本すべてを「仲介層を経由する起動方式」から「Claude CLI を直接呼び出す方式」へ移行完了した。動機は信頼性だ——仲介層が tool denial を返すと処理が途中終了するという根本的な不安定要因を取り除いた。結果として全 9 本が安定稼働し、MTG 議事録生成・インテル収集・記事執筆・コラム投稿が無人で完走するようになった。
◾️ 背景：なぜ仲介層が問題だったのか
当初、スケジュール実行は「実行基盤が Claude に対してツール呼び出しを仲介する」構成だった。この構成にはひとつ根本的な脆弱性がある——実行主体が許可されていないツールを呼ぼうとした瞬間に処理が止まる。
インタラクティブなセッションなら人間がその場で判断を下せる。しかし無人実行では「止まった」こと自体を誰も検知できない。朝に走るはずだった MTG 議事録生成が実は途中終了していて、そのまま空っぽのまま一日が始まる——そういうシナリオが実際に発生した。
パーミッション設定で対症療法を試みた。スケジュール実行環境にも幅広い権限を付与する設定だ。しかしこれは「許可リストを広げる」アプローチであり、設定のドリフトに弱い。新しい処理が追加されるたびに許可の確認が必要になる。
根本的な解決策として選んだのが CLI 直接起動 だ。
◾️ 移行パターン
変更の骨格は単純だ。
移行前の構造
実行基盤 → 仲介層を通じて Claude を起動 → Claude がツールを呼ぶ
↑
ここでツール許可の判断が分散・衝突する
移行後の構造
実行基盤 → Claude CLI を直接呼び出す → Claude がツールを呼ぶ
↑
ツール許可の判断は CLI の設定に一元化
仲介層が消えることで、ツール許可の判断は CLI の設定に集約される。実行基盤側が「どのツールを使って良いか」に口を出さなくなるため、設定の整合性を維持する負荷が激減する。
加えて、CLI 呼び出しの際にプロンプトを実行ファイルへ直接埋め込む方式を採用した。処理ごとの指示が実行ファイルに収まることで、「プロンプトの場所」が散らばらなくなる。実行ファイルを読めば動作の全体像が一目でわかる構造だ。
◾️ 9 本の移行順序と途中で判明した追加課題
移行はまず MTG 議事録生成から始め、問題がないことを確認してから順次拡大した。
- MTG 議事録生成（検証の起点）
- 日次記事執筆・反応型記事
- インテル収集（政策・公式情報）
- ロードマップ更新
- 月次レポート・画像改善フィードバック
- 副社長コラム投稿
6 本目あたりで新しい問題が顕在化した。複数の処理が同じ時間帯に走ると、リポジトリへの push が競合する。
具体的には:
- A 処理が午前 5 時に起動、記事を生成して push しようとする
- B 処理が同じく午前 5 時に起動、別のファイルを push しようとする
- どちらかが先に push に成功すると、もう一方は「リモートが先行している」として push を弾かれる
解決策は rebase + 最大 3 回リトライ だ。push が失敗したら最新のリモートを取り込んで rebase し、再度 push を試みる。これを最大 3 回繰り返す。3 回失敗した場合はエラーを記録して終了する。実測では、ほぼすべてのケースで 1〜2 回目のリトライで成功している。
◾️ 運用監視：ステータス集計の自動化
9 本が安定稼働するようになると次の課題が浮かび上がった——「どの処理が最後にいつ動いたか」を確認する手段がない。
失敗した場合、ログを掘れば分かる。しかし「掘らないと分からない」状態は運用として脆弱だ。インシデントに気づくのは常に遅れる。
対処として、1 時間ごとに各処理の最終実行日時・成否を集計して JSON ファイルとして書き出す仕組みを追加した。管理画面にこの JSON を読み込んで一覧表示するページを設けた。
ここで小さいが重要な設計判断をした。集計 JSON はアクセス制限なしで読める場所に置く。管理画面自体は認証付きだが、JSON ファイルはパブリックな URL に配置する。この設計には理由がある——認証情報（PAT）の設定が不完全な環境でも、管理画面から実行履歴を閲覧できるようにするためだ。
「完全なセットアップ」と「最低限の監視」を切り離すことで、セットアップが途中の段階でもステータス確認だけは維持できる。インフラ整備の初期フェーズにおいて、これは運用の安全弁として機能する。
◾️ 教訓と SOP 化
今回の移行から引き出した原則を記録しておく。
原則 1: 無人実行に「止まらない設計」より先に「止まっても検知できる設計」を
処理が途中終了しても誰も気づかないのが最悪のパターン。まず検知できる状態にしてから、止まらない設計に取り組む。検知がないまま信頼性を追求すると、問題の所在が見えなくなる。
原則 2: 許可の判断は一箇所に集約する
ツール許可の判断が実行基盤・仲介層・CLI の複数箇所に分散しているほど、設定のドリフトが起きやすい。新しい処理を追加するたびに全箇所の整合性を確認するコストが累積する。判断を一箇所に集約する構造を維持することが、スケールアップ時の運用負荷を抑える。
原則 3: 並列実行のリソース競合はリトライで吸収する
自動化処理が増えるほど、同時実行による競合は必然的に増える。競合を「起きないようにする（実行時刻を完全に分散させる）」より「起きたら自動回復する（rebase + リトライ）」設計が現実的だ。リトライ上限は必ず設けて、無限ループには落とさない。
原則 4: 運用監視は認証から切り離す
実行状況の確認が認証に依存すると、インシデント時に「確認する前に認証の問題に当たる」という二重の障壁が生まれる。ステータス情報はパブリックアクセス可能な形で持つことで、誰でも・どの環境からでも現状を確認できる状態を維持する。
今週で自動化インフラの基盤がひと区切りついた。次のフェーズは「処理が失敗したときのアラート」だ。現状はログを能動的に見に行かないといけない。プッシュ通知か外部連携か、実装コストと実用性のバランスをどこに置くかを判断する予定だ。「9 本が安定稼働している」という状態は手に入った。次は「9 本が落ちたとき、30 分以内に気づける」状態を目指す。