タグ
#Claude Code
Claude Codeに関する記事を公開しています。
障害検知のトリアージから対応まで AI エージェントに任せる設計手法例
監視アラートの一次判定から修正の PR まで AI エージェントに任せ、判定に使う道具を読み取り専用に絞った設計。13週間で起票14件、人の本番操作0件。
戻せない D1 マイグレーションは本番のダンプで先に流す
EmDash は merge した瞬間に本番の D1 スキーマを自動で書き換える。down が空で戻せない 2本を含む 20本のアップグレードを、本番のダンプに先に流して検証してから通した設計を記す。
サンドボックスに鍵を置かずに EmDash の CLI を使う
CMS への記事投入を内蔵 MCP 経由で行うと本文がモデルの入出力を通り、トークン消費も文字化けの危険も増えます。サンドボックスの環境変数にプレースホルダーを置き、ホストのプロキシが差し替える経路に切り替えた設計を実例で示します。
X 公式 MCP が Docker サンドボックスで認可できない
X 公式 MCP を Docker サンドボックスから直接使おうとすると認可サーバーの制約と噛み合わない。接続して分かったツールの中身と読み取りの単価を示し、認証をホスト側のブリッジに置く設計を記す。
AI エージェントに X の鍵を渡さず投稿させる権限設計
X 公式 MCP に投稿ツールが無い前提で、鍵を neta-bot だけに残したまま AI エージェントに X へ投稿させる権限設計を実例で示します。承認は会話に一本化し、投稿口は 1 つに閉じて台帳に必ず載せます。
AI エージェントの記憶を git だけに置き環境は捨てる「秘書戦略」
サンドボックスは作り直すと中身がすべて消えます。事業の判断・手順・議事録を責務ごとに git の文書へ分けて置き、規約の書き換えだけを PR 必須にする、消える環境を前提にした記憶の設計を実例で示します。
GitHub Actions の OIDC で AWS の鍵を手元から無くした
Claude Code の Docker Sandbox に AWS の認証情報を渡すスクリプトを 3 本書きましたが、docker sandbox exec が別のコンテナに書き込んでいて一度も機能していませんでした。渡すこと自体をやめ、Terraform の bootstrap 層(Actions が引き受ける IAM ロールと OIDC)まで GitHub Actions の workflow_dispatch で plan / apply する構成にしました。ロールが自分自身を書き換える権限の線引きと、信頼ポリシーのリポジトリ名の既定値が古いままで自分を締め出しかけた話も残します。
changesets を AI エージェントに書かせると変更履歴が読める物になる
8 サイトのモノレポの変更をほぼ AI エージェントの PR で回していると、git log では「あのサイトはいつ何が変わったか」を追えなくなりました。changesets を入れ、PR を作るその瞬間にエージェントへ変更記録を書かせ、Release PR の merge でサイトごとの CHANGELOG に集約する形にしました。誤った記録を次の記録が訂正して並ぶ実例と、別リポジトリで踏んだ罠(タグの系統が 2 つになる、changeset status は commit 済みしか数えない、Release PR の merge がデプロイになる)を書きます。
.github リポジトリの PR テンプレートに「ハマったこと」欄を置く理由
AI エージェントに gh pr create --body で PR を作らせると、リポジトリの PR テンプレートは使われません。適用されるはずだと思い込んでいて、しばらく気づきませんでした。組織の .github 公開リポジトリにテンプレートを 1 つ置いて全リポジトリの既定にし、エージェントには「テンプレートを先に読んで本文を組む」手順を渡しました。テンプレート末尾の「ハマったこと・試行錯誤」欄は、commit には残らない物語を作業直後に残す場所で、別の bot が毎朝拾って素材にします。拾う側の本文上限が 300 文字で、一番下にあるこの欄ごと落ちていた失敗も書きます。
Claude Code の Docker Sandbox で API キーが渡らない原因
Claude Code の Docker Sandboxes で、sbx secret で入れたはずの API キーが環境変数に現れない、gh CLI が一部のコマンドだけ失敗する、という 2 つの症状に当たりました。正体はどちらも、プロキシがネットワーク層で認証を注入するというこの環境の設計です。direct モードでの実用解(ホスト側に .env を置く)と、gh の更新系操作を読み戻しで検証する運用を実測ベースで書いています。
Claude Code のサブエージェント並列でサイト群を保守する
AI コーディングエージェントを「1 人のアシスタント」ではなく「司令塔 + 並列の実働班」として編成し、本番の複数サイトを日々保守している運用の設計を書きます。git worktree での物理分離、指示書に埋め込む計測プロトコル、権限の非対称、司令塔による二重検証、人間の介入点の切り分け。実際に出荷を止めたガードレールや、報告と実体の乖離といった実例と、この方式の限界まで含めてまとめます。
AI エージェントを自走させるのはプロンプトではなくハーネス
AI コーディングエージェントの自律性を支えるのは長い指示書ではなく、成果物を機械的・決定的に合否判定する検証系(ハーネス)です。LLM は確率的、ハーネスは決定的というこの非対称を、決定的パイプライン・Claude Code の Hooks・ドメイン固有の検証プロトコル・観測とフィードバック・権限という5つの層に整理し、人間の介入点をどう絞るかを実運用の事実に沿ってまとめます。
Claude Code のチーム機能とサブエージェントの使い分け
「チーム機能はエージェント同士が P2P で連携できる。サブエージェントは親に報告するだけ。なら常にチームが上位互換では?」という直感に、両者の機構の違いから答えます。サブエージェント並列を実務で回している立場から、指示書が書けるか否かという一本の判断基準まで整理しました。