プラグイン・スキルファイル・デッドロック：拡張機能と並行性の問題を理解する
約11分developer-tools
#プラグイン#スキルファイル#自動承認モード#デッドロック#レースコンディション#AIコーディングツール#用語集
※編集方針：以下の業務状況および人物は、用語の理解を助けるための架空のシナリオです。実際の著者の経験や特定企業の出来事を再現したものではありません。
ごく稀に発生する在庫処理の並行性バグを解決するために、ログを追跡する架空の状況を想定してみます。
同僚が少し前のコミットで何かをインストールした形跡を発見し、なぜログのフォーマットが突然変わったのかが理解できました。
ツールの機能が突然一つ増えているとき：プラグイン
text
1Loaded plugin: log-formatter-pretty
同僚の過去のコミットを調べてみると、ログをより読みやすく整理してくれる拡張機能を一つインストールしていました。ツール自体のコア機能はそのままに、必要な機能だけを別途作成して後から組み込めるようにする方式でした。本体はそのままで必要な部品だけを交換するのに似ていました。おかげでログが非常に見やすくなりました。
ログをさらに整理して見ていると、エージェントが何かを実行する直前に、特定のファイルを参照しているというメッセージを自ら出力しているのを発見しました。
エージェントが特定の方式でのみ処理を行うとき：スキルファイル
text
1Using skill: systematic-debugging
画面に表示されたメッセージを見て分かりました。特定の状況でどのような順序、方法で問題を解決すべきかをあらかじめまとめた手順書を、必要なときに呼び出してそのまま従わせる方式でした。シェフが状況ごとのレシピカードを事前に用意しておき、その都度取り出して確認するようなものでした。現在は、並行性バグを体系的に絞り込んでいく手順に従っていました。
手順に沿ってファイルを一つずつ開いていくと、以前、事例内の担当者が設定しておいたオプションが一つ目に留まりました。
承認ウィンドウが一つも表示されなかった理由：自動承認モード
json
1{ "autoApprove": ["Read", "Grep", "Bash(git *)"] }
数ヶ月前、毎回読み取りコマンドまでいちいち承認するのが面倒で、このように設定していたことをすっかり忘れていました。リスクが低いと判断された特定の種類のタスクは、毎回確認せずにすぐ実行されるように事前に許可しておく設定でした。おかげで、今夜のようにログを読み込んで検索するプロセスが途切れることなくスムーズに進められました。
ついにログの真ん中で疑わしい箇所を見つけました。2つの処理プロセスがまったく同じ瞬間に停止していました。同様の停止がログのあちこちで繰り返されていました。
2つのタスクが互いを待ち合って永久に停止するとき：デッドロック
text
1Thread-A: waiting for lock(inventory)2Thread-B: waiting for lock(order)3Thread-A holds lock(order), Thread-B holds lock(inventory)
同じパターンがログに何度も繰り返されているのを見て、ようやく原因を確信しました。一方が他方の保持するリソースを待ち、その他方がまた最初の一方の保持するリソースを待つことで、互いに譲ることなく永久に停止してしまう状態でした。一本橋で鉢合わせした二人が、互いに道を譲るのを待つうちに、二人ともその場で動けなくなってしまったようなものでした。
なぜこのバグが数週間に一度しか再現しないのかも、そのときになってようやく検索して突き止めました。
あるときは動き、あるときは動かないとき：レースコンディション
同じコードなのに、なぜ常に発生するのではなく、たまにしか発生しないのか疑問に思い調べてみました。2つのタスクがリソースにアクセスする順序が、毎回正確に同じではないことが核心でした。
2つのタスクがごくわずかなタイミングの差でリソースに先に到達する方が毎回異なり、あいにく特定の順序で重なったときだけ、事例内の担当者が浮き彫りになる現象でした。同じ合図でスタートしても100分の1秒の差で順位が分かれる徒競走のように、毎回先に到達する方が変わりました。トラフィックが集中する特定の瞬間にのみ2つのタスクがそのタイミングで重なるため、再現がそれだけ困難でした。
原因を確実に突き止めた頃には、窓の外はすでに明るくなっていました。ロックをかける順序を統一する修正だけで、デッドロックとレースコンディションを同時に解決することができました。
よくある質問
自動承認モードは危険ではありませんか？
読み取り専用タスクのように、元に戻す必要がない種類のみを許可しておけば、大きなリスクはありません。ただし、削除やデプロイのように取り消しが困難なタスクまで自動承認に含めることは推奨されません。
デッドロックはなぜ事前に検出するのが難しいのですか？
コード自体はそれぞれ正常であるため、構文チェックでは検出されません。実際に複数のタスクが同時に実行される状況でのみ発生するため、実行フローを再現するテストが別途必要になります。
レースコンディションはテストで常に検出できますか？
タイミングに依存する問題であるため、通常のテストでは再現しないことがよくあります。同時リクエストを大量に発生させる負荷テストや、意図的にタイミングをずらす専用ツールを使用する方が効果的です。
AIコーディングツール用語集シリーズの第13話です。次回予告 · 第14話：年末のセキュリティ監査を準備しながら一年を振り返った日 監査ログ · プランモード · ヘッドレスモード · セマフォ · コアダンプ
参考・根拠
関連記事
サブエージェント・フック・スラッシュコマンド：AIコーディングツールでよく使われる拡張概念
AIコーディングツールの使用中に出会う「サブエージェント」「フック」「スラッシュコマンド」を、架空の業務シナリオを交えて分かりやすく解説します。
パーミッションプロンプト・Sandbox・Checkpoint：AIエージェントの実行境界を理解する
AIコーディングツールを使う中で直面するパーミッションプロンプト、サンドボックス、チェックポイントなど5つの用語を、仮想の業務シナリオを通じてわかりやすく解説します。
Kill Switch・Backoff・Runtime：実行を停止し復旧するための基本機能
AIコーディングツールを使っていると遭遇する、キルスイッチ、バックオフ、リポジトリなどの5つの用語を、仮想の業務シナリオを通じてわかりやすく解説します。