Audit Log・Plan Mode・Headless：エージェントの運用と監査に必要な用語
約12分developer-tools
#監査ログ#プランモード#ヘッドレスモード#セマフォ#コアダンプ#AIコーディングツール#用語辞典
※編集方針：以下の業務状況および登場人物は、用語の理解を助けるための仮想シナリオです。実際の著者の経験や特定企業の出来事を再現したものではありません。
仮想の運用チームが年末のセキュリティ監査を控えて、1年間のシステム変更履歴を提出しなければならない状況を考えてみましょう。
どこから抽出したものかと悩みながらログを調べ直してみると、すでに必要なものはすべて1箇所に蓄積されていました.
誰が・何を・いつ変更したのかが丸ごと残っていた理由、監査ログ
text
12026-03-14 14:02 user:jiho action:deploy target:payment-service22026-03-14 14:05 user:jiho action:permission-change target:admin-panel
1年分のログを再び開いてみると、誰がいつ、どのような作業を行ったかが、一つ残らず時系列で残っていました。人が個別に記録しなくても、システム自体がすべての重要な行動を自動的に記録する、独立した記録でした。普段は誰も見向きもしないのに、問題が発生して初めて見返すことになる、銀行の防犯カメラのような記録でした。監査機関にこのログをそのまま提出しました。
ログ를 整理していると、今年1年、本当に大きな変更作業を行う前に必ず最初にオンにしていた、あるモードが頭に浮かびました。
大きな作業の前、コードを書き換える前にまず確認する理由、プランモード
入社直後、先輩社員が教えてくれた習慣でした。「危険な作業であるほど、まずは計画を立てさせてから実行させろ」
text
1[PLAN MODE] 코드를 수정하지 않고 계획만 세웁니다.
実際にファイルを修正する前に、どのような手順で何を変更するかという計画をまず立て、人間がその計画をレビューした上で実行に移す方式でした。家をリフォームする前にまず設計図を確認してもらうようなもので、この習慣のおかげで、今年は大きなトラブルなく乗り切れた作業がいくつもありました。
監査資料に自動化パイプラインの項目も含める必要があったため、CIサーバーの設定を調べ直しました。画面が一切ないのに、なぜ毎回勝手に実行されるのか、公式ドキュメントにその答えがありました。
画面もなしにサーバーが自動で処理を行う理由、ヘッドレスモード
bash
1$ claude --headless "테스트 실행하고 결과 요약"
ドキュメントを見ると、人間が画面を見ながら対話する方式のほかに、このように利用できる方式が別に存在していました。画面や対話ウィンドウなしで、コマンド一つで実行され、結果だけがファイルやログとして残る方式でした。人が監視していなくても、あらかじめ決められた手順通りに勝手に稼働する無人店舗のようなものでした。今年1年、夜間に自動で実行されていたテストは、この方式のおかげでした。
パイプラインのコードを眺めていると、数ヶ月前に同僚が作成したある設定がなぜ存在するのか気になりました。
同時に大量のリクエストが集中しないように制限するもの、セマフォ
js
1const semaphore = new Semaphore(5); // 동시에 5개까지만
同僚が以前に書いておいたコードを見ると、外部APIに同時に大量のリクエストが集中したことでブロックされた過去があり、それ以降この仕組みを導入したと書かれていました。
指定された上限数まで同時に通過させ、残りは待機させる信号機のような仕組みでした。狭い通路に一度に5人ずつだけ通し、残りは並んで待たせるようなものです。この設定のおかげで、今年は同じ問題が再発することはありませんでした。
監査資料をほぼ集め終えた頃、今年初めに発生した大規模障害の原因調査ファイルがフォルダーの片隅に残っているのを見つけました.
サーバーが完全に停止したときに残る最後の痕跡、コアダンプ
text
1Segmentation fault (core dumped)2core.12045 generated
ファイルサイズが数百メガバイトもあるこのファイルを最初に見たときは何なのか分かりませんでしたが、システム自身が残した説明のおかげで理解できました。プログラムが突然停止した際、その瞬間のメモリ内のすべての状態をそのまま1つのファイルに凍結して残す方式でした。事故現場をそのまま封鎖しておき、後から鑑識チームが再現するようなものでした。このファイルのおかげで当時の障害原因を正確に特定でき、今年の監査報告書にも原因と再発防止策を合わせて記載することができました。
監査資料をすべて集め終える頃には、窓の外はすでに暗くなっており、オフィスには数人しか残っていませんでした。
第1話で「サブエージェント」が何なのかも分からず戸惑っていたのは、まさに今年の初めのことでした。その間にフック、スラッシュコマンド、サンドボックス、コンパイル、デッドロックといった聞き慣れない言葉を、一つずつ実際に直面しながら身に付けていきました。振り返ってみれば、当時は耳慣れなかった言葉の一つひとつが、その瞬間には困惑させられたとしても、最終的には次に出会ったときにより早く理解するための道標の役割を果たしてくれました。
よくある質問
監査ログはどのくらいの期間保管する必要がありますか？
業界や規制によって異なりますが、一般的には最低1年以上の保管が求められることが多いです。ストレージコストを考慮し、古いログは圧縮して別のアーカイブ（保管場所）に移す方式が採られます。
セマフォの値（同時実行数）はどのように決めますか？
決まった正解はありませんが、接続先サーバーが処理できる同時リクエスト数を参考に決定します。少なすぎると待機時間が長くなり、多すぎると本来防ごうとしていた問題が再発する可能性があります。
コアダンプファイルは誰でも開いて見ていいのですか？
その瞬間のメモリ状態がそのまま保存されているため、機密情報が含まれている可能性があります。調査目的であってもアクセス権限を制限し、確認が終わったら安全に削除するのが賢明です。
前回の記事 · 第13話、並行処理의 バグを潰すために一晩中ログを追った日
AIコーディングツール用語辞典シリーズの第14話です。シリーズの締めくくりとして、AIコーディングツール用語辞典は第14話で完結となります。第1話の「サブエージェント」から第14話の「コアダンプ」まで、70個の用語を実際に直面しながら整理しました。ご愛読いただきありがとうございました。
参考・根拠
関連記事
サブエージェント・フック・スラッシュコマンド：AIコーディングツールでよく使われる拡張概念
AIコーディングツールの使用中に出会う「サブエージェント」「フック」「スラッシュコマンド」を、架空の業務シナリオを交えて分かりやすく解説します。
パーミッションプロンプト・Sandbox・Checkpoint：AIエージェントの実行境界を理解する
AIコーディングツールを使う中で直面するパーミッションプロンプト、サンドボックス、チェックポイントなど5つの用語を、仮想の業務シナリオを通じてわかりやすく解説します。
Kill Switch・Backoff・Runtime：実行を停止し復旧するための基本機能
AIコーディングツールを使っていると遭遇する、キルスイッチ、バックオフ、リポジトリなどの5つの用語を、仮想の業務シナリオを通じてわかりやすく解説します。