エンジニアのAI活用事例

個人開発のプロジェクトが4〜5件同時に走り、実装よりも「今週どれを進めるか」を決める時間が膨らんでいた。

判断が溜まり続けて、放置される案件も出ていた。

1. オーナーは自分だと伝え役割別エージェント作成をClaude Codeに依頼する
2. 返ってきた質問に答えて自律の範囲とモデル配分を決める
3. 承認をDiscordとPCの両方から行えるか確認し計画を一度差し戻す
4. 9役割を定義し自動可と承認要の一覧表をCLAUDE.mdへ固定する
5. 決裁は1件1枚のMarkdownカードにしてディレクトリ移動で状態を表す

サブエージェント9体とスラッシュコマンド、初回会議の成果物まで含む骨組みが59ファイルの1コミットで立ち上がった。

スラッシュコマンドは最終的に7個になり、今はこの仕組みの下で大小10個前後の事業が動いていて、決裁待ちはコマンド1つで一覧できるようになった。

買い替えたSnapdragon X2 Elite搭載のWindowsノートPCでローカルLLMを動かしたかったが、どの実行経路とモデルが使えるかを一つずつ試すのは手間が大きかった。

1. Claude CodeをPCに入れる
2. NPUでLLMを動かす経路の調査とベンチマークをAIに任せる
3. 1モデル1プロセスで温度やseedを同じにそろえて計測する
4. 短文タスクと論文全文の査読メモ作成を走らせる
5. 速度とロード時間とRAM増加量を記録し翻訳品質は自分で確認する

NPUを全層使うqairt経路ではQwen3 4B Instruct 2507が37.1tok/sで動き、英→日1,229字の翻訳が10.4秒で終わった。

コンテキスト長4096固定という制限はあるが、翻訳や要約なら実用になると分かった。

Databricks上でRAGチャットボットのPoCを進めていたが、回答の精度が悪いときに原因がチャンク分割か検索か質問か回答生成かを見分けられなかった。

全部に手を入れるしかないと感じ、着手点が決まらない状態が続いていた。

1. LLMOpsの勉強会と書籍で可観測性を知り既存コードに手を入れた
2. コード生成AIに相談し関数ごとにMLflowのトレース用デコレーターを付けた
3. アプリを動かしExperimentsで記録の抜けを見つけ順に見えるようにした
4. 自動トレーシングも戻す前提で試し重複する記録は後から外した
5. 検索で返った文書とチャンクの単位で中身を確かめた

約1ヶ月このやり方を続け、検索結果が同じ文書内のチャンクに偏る現象を見つけて検索ロジックの見直しにつなげた。

どの工程が悪いのかを部品ごとに見分けられるようになり、気持ちの負担も手間も大きく減った。

夫婦生活費と子ども費とその他という独自の3分類が必要で、既存の家計簿アプリのカテゴリでは合わなかった。

そのため買ったものを一つずつレシートから拾って電卓で足す手作業が家庭内で続いていた。

1. 仕様の原典になる文書の構成をAIと決める
2. 作りたいものを音声入力で話し質問に答える
3. 文書間の食い違い10件を検証役が直す
4. データモデルと分類ルールと認証の3節を読み保留4件を決める
5. テスト駆動で4回に分けて実装させる

自分が手を動かした時間は2〜3時間で、コードは1行も書かなかった。

AIが書いたテストは330本で、テストを通ったあとに見つかったバグは1件だった。

家庭内の電卓での集計もなくなった。

自作タスク管理ツールに繋いだAIエージェントをcronで定期実行していたが、進めるタスクが無い時間帯でも同じ間隔でLLMが起動していた。

空振りの実行でトークンを消費し、中身のない通知がSlackに流れ続けて重要な知らせが埋もれていた。

1. LLMを呼ぶ手前に起床判定の関数shouldWakeForTaskを置いた
2. 関数はタスク1件と利用者IDを受け取りbooleanだけ返す
3. 状態はタスクコメント1行目のマーカーに書き正規表現で読む
4. 最新マーカーはcreatedAtで選び再アサインなら再び起こす
5. 起こす条件と寝かせる条件をユニットテストで固定した

waitingやdoneのように待つべき状態では起動せず、再アサインや依存の解消、中断した作業の再開だけをエージェントに回せるようになった。

ただし定義外の状態名が入るとゲートが起床させない側に倒れる点は課題として残った。

Claude Codeが使うトークンの約9割が、込み入った推論ではなくファイルの読み込みや定型コードの出力に消えていた。

高価なモデルに単純作業まで任せる状態が続いていた。

1. 読む担当bulk-readerと書く担当code-writerの2モードを作る
2. 作業用モデルにGemini 2.5 Flashを割り当てる
3. bulk-readerで大きなファイルを読み要約だけをClaudeへ返す
4. code-writerは参考ファイル指定を必須にしひな型を出力させる
5. shuntのPreToolUseフックで350行超の読み込みを止める

Javaのモノレポで4種類の場面を試したところ、bulk-readerを通したケースでClaude側のトークン消費が平均で約90%減った。

一方で軽量モデルはスレッドセーフティーに関わる問題を見落とすことがあった。

2人で予定を共有するために自作したカレンダーアプリに写真アルバムを足したかったが、既存の予定データを壊す不安があった。

着手前に本番のFirestoreルールを見ると誰でも読み書きできる状態だった。

1. Claude Codeに「既存データは壊さず追加のみ」と条件を渡す
2. Firebase MCPで本番ルールを取り出し差分を確認して書き換えた
3. メール確認済み判定をUID判定へ人が切り替えた
4. エミュレータでテスト後にデプロイし本番と一致を確認した
5. CORSが必要という説明は実測させて誤りを訂正させた

実働は約6時間40分で23commits、55ファイル、+5,303/−416行まで進んだ。

セキュリティルールのテスト28件とCloud Functions12個を用意し、写真・動画のアルバムやLINE共有まで動かせた。

コード量を54%減らせるとうたうプラグインの数字が、自分の環境でも同じように出るか分からなかった。

モデルごとの向き不向きも判断できなかった。

1. Express製55行のTODO APIに日本語4行のチケットを7本用意する
2. headlessのclaude -pにチケットを渡し実行する
3. --plugin-dirで足す条件と足さない条件を作る
4. Haiku・Sonnet・Opusの3モデルで合計42セルを回す
5. 差分を同じprettier設定で整形し直してから数え直す

削減率は9〜25%にとどまり、54%は再現しなかった。

コストが下がったのはOpusだけで、Haikuは1件テストを落とした。

自作のタスク管理CLIのバグ修正をClaude Codeに任せていたが、1件直すたびに新しいバグ報告が生まれる感覚が続いた。

AIが自分の仕事を残すためにIssueを作っているのではないかと疑った。

1. 引数処理のバグのIssueを5パートに分けて順に修正させる
2. レビュー時に同じ構造が他に無いか横断で調べさせる
3. 見つかった箇所を新しいIssueとして起票させる
4. 1日分の起票数とクローズ数を手で数え8日分に広げる
5. nextの箱に積むかは人が決める運用に固定する

テストは1,747件から1,914件に増えた。

8日間の収支は起票7件・クローズ14件で、somedayの箱は77件から71件に減り、増加傾向には転じなかった。

原因はAIではなく網羅を求める指示の書き方だと分かった。

定期で走るはずの処理が3日間止まっていたのに誰も気づかなかった。

エラーが出ないまま止まるので、毎日見ていても異常が異常として現れなかった。

1. Claude Codeのセッションを役割で分け統括の下に実作業を並べた
2. セッション間はinbox配下のマークダウンで連絡し人間は統括だけに話す
3. 点検用のルールベーススクリプトを朝夜に走らせた
4. 閉じ忘れや返事なしなどを数え3段で判定しJSONLに残した
5. 定期ジョブが消えるためスケジューラをOS側のlaunchdへ出した

77日の運用で自動巡回は120回走り、異常なしで終わったのは9回（7.5%）だった。

検出311件のうち例外を投げたものは1件だけで、その1件も巡回スクリプト自身の通信エラーだった。

実装が終わった後に別モデルへレビューさせる流れが一般的だが、手戻りが大きいのはコードの欠陥より計画の欠陥だった。

サブゴールの切り方や依存関係の矛盾は、下流でいくら磨いても直らない。

1. 計画立案とコードレビューをClaude Codeに固定する
2. 計画の穴探しと実装をCodex側に固定する
3. 起動時にインタビューでゴールと非ゴールと受入条件を文書化する
4. JSON Schemaに沿ったverdictで計画を検証し最大3回まわす
5. 検証は読み取り専用にしてコミットは人間が行う

品質のチェックを実装後ではなく計画段階に移し、重大な指摘がゼロになってから実装へ進む流れになった。

判定の根拠がファイルに構造化されて残るため、後から見返すこともできるようになった。

詰まったところだけ質問する使い方では判断を全部自分が抱えることになり、開発の速さは1.3倍ほどで止まっていた。

ファイル編集のたびに許可を求められて作業が数分おきに止まっていた。

1. 最初にAIへ権限の表を渡した
2. 機能の順番を決める設計だけ人が確認する形にした
3. ファイル編集やマイグレーション、gitコミットは確認なしで進めさせた
4. 外部サービスへの実アクセスは目的を一言伝えさせPCやお金の操作は対象外にした
5. 報告は1時間に1回にまとめ変更ファイル名と設計理由を残させた

社内の顧客管理システムを約6週間で作り、PHPファイル74本、約3,500行のコードはほぼ全てClaude Codeが書いた。

開発に使う時間は1日15〜30分になった。

アプリ開発は素人で、Androidのカメラアプリを一人で作り切る時間も経験も足りなかった。

チャットで相談する形だと実機での動作確認まで手が回らなかった。

1. エージェント型のClaude CodeとCodexを併用しQwenも追加した
2. AGENTS.mdに全AI共通のルールを置き実測か未検証を明示させた
3. 実機投入時はAPKと端末のSHA-256一致まで確認させた
4. hookでadb uninstall等の危険なコマンドを機械的に止めた
5. 課題は自己完結HTMLのWBSで管理し実機5台で目視確認した

2026年7月23日から約50日でGoogle Playのクローズドテストまで到達した。

API従量課金なら約60万円分に当たる使用量を、月額プランの枠内で実費約1.5万円に収めた。

1人で回すWeb制作会社では、顧客管理や請求まわりの社内システムを自力で作る時間が足りなかった。

店舗向けサイトの雛形づくりにも手が回らなかった。

1. Claude Codeを開発担当の社員のように位置づける
2. 作るものの設計を先に固めて合意してからコードを書かせる
3. 指示の粒度を調整しLaravel12のモジュール構成に沿わせる
4. Stripe Cashierなど詰まりやすい箇所は自分で確認して直す
5. 完成したものをさくらのレンタルサーバーに載せて運用する

顧客管理とStripe請求、Instagram連携を持つ社内CMSと、予約や会員機能とLINE連携を備えた店舗サイトの雛形を作り上げた。

制作の過程は約57,889字の記録としてまとめた。

バッチ処理の途中でレート制限のエラーが続き、とりあえず待って再実行するという場当たりの対処をしていた。

その結果リトライが重なって制限をさらに食いつぶす悪循環になっていた。

1. 例外を文字列でなくクラスで捕まえ、429と529を分岐させた
2. 生のレスポンスから制限種別と待ち時間のヘッダーを常時確認した
3. リトライはPython SDKの自動リトライ回数に任せ外側では書かない
4. 自前で組む場合はSDK側の回数を0にして役割を一つにまとめる
5. 残トークン数のヘッダーで同時実行数を絞り入力トークンを事前に数える

外側のリトライを重ねた状態では1回の処理が最大9回のリクエストに膨らんでいたが、役割を分けて解消した。

エラーをただ待って潰すのをやめてヘッダーを読むようにしたことで、バッチの安定性が目に見えて変わった。

AIエージェントへの指示が長い間ためこまれ、どれが今も効いているのか分からなくなっていた。

中身が古くなっても本人が気づけない状態だった。

1. 手元の指示ファイルとメモリを全部探し行数を数えた
2. 最大の392行ファイルを節ごとに分け行数順に並べた
3. 大きい節から直近1か月で使ったか自分に問うた
4. 消す・残す・別ファイルに逃がすの3つに仕分けた
5. 認証情報らしき文字列が混ざっていないか検索した

392行のうち大きい3節の合計181行が1か月間1度も使われておらず、1ファイルの46%が不要と分かった。

あわせて認証情報らしき2行も見つかった。

副業で受けた開発案件に時間がかかりすぎ、報酬に対して実質の時給が下がっていた。

ツールを1つに絞ると得意でない工程で手が止まる。

1. 案件を4タイプに分けて使うツールを先に決める
2. 既存コードの修正はGitHub Copilotの補完提案をそのまま試す
3. 小規模サイトはCursorで骨組みだけ手書きし残りを生成させる
4. 中規模アプリはClaudeに画面構成とAPI設計とDB設計を出させる
5. 要望があいまいな案件はClaudeで機能候補と優先順位を整理する

ポートフォリオサイト制作は8時間で終わり、所要時間が60%削減された。

中規模アプリ開発は約120時間で、所要時間が40%削減された。

ProプランでClaudeとClaude Codeを毎日使っていたが、5時間や1週間ごとの上限に当たって作業が止まる場面が増えていた。

1. CLAUDE.mdとrulesを必要最小限に削る
2. そのプロジェクトに要るskillsやmcpだけ読み込ませる
3. 対象ファイルのパスと参照元を先に渡し変更後の姿まで書く
4. 単純な調査はサブエージェントに任せ判断を本体に残さない
5. 話題が変わったら新セッションに移り区切りで/compactする

人が既に知っている情報を先に渡し、本当に探索が要る部分だけをClaudeに任せる形にしたことで、体感できるほどトークンの持ちが変わった。

context-modeはフックが有効な環境で最大約98%のトークン削減が見込めるとされる。

複数のAIが会話する様子を見せるだけのデモが多く、出来上がったファイルの作られ方や検証の通過状況をあとから追えなかった。

ログばかりが目立って成果物が脇役になっていた。

1. 一文の依頼からMasterが成果物と前提と依存関係を構造化出力で提案する
2. Runtimeが計画のスキーマや循環や担当や書込範囲や上限を先に検査する
3. 各Botに受信箱と作業領域を持たせ担当タスクと入力の参照だけを渡す
4. ReviewerがSHA-256のリビジョンに紐付けて検証し不合格ならBuilderが直す
5. 最終報告をモデルの要約ではなくイベントログから組み立てる

日本語の紹介LPとSNS投稿草案3案を頼んだ実行では、index.htmlやposts.mdなどが出てプログラム検証10件すべてがpassした。

Reviewer判定も6/6になった。

39ターンで$1.66、18分37秒で完了した。

77件のイベントログを無編集で公開している。

同じテンプレートからブラウザのプレビューとサーバのPDFが違う出力になり、24要素中18種が例外もログも出ないまま空で描画されていた。

既存テストはPDFが生成されたことしか見ておらず、ずれに気づく手段が目視比較しかなかった。

1. AIにコード全体をレビューさせEpicと子Issueを作らせた
2. 提示された12件から着手順を人が決めテスト基盤を最初に指定した
3. Issue番号と進める部分だけを10〜30分単位で指示した
4. 仕様が無い部分は実装前にAIへ仕様書を書かせた
5. Epicを閉じる条件に目視比較を加えて指示した

7月16日に立てた#52〜#64の13件はすべてその日のうちに閉じた。

ゴールデンPDFの回帰テストが安全網になり、フォントファイルの中身が違う問題や約1.4mmの縦ずれといった細かい差も特定できた。

CiscoやJuniperなどベンダーごとにコマンドの書き方が違い、手作業での置き換えに手間がかかっていた。

正規表現で作る変換スクリプトは複雑な設定や独自構文ですぐ壊れてしまう。

1. Bolt.newに2つの機器設定を左右で比べる画面を作らせた
2. 仮の変換処理をGemini APIの呼び出しに差し替えた
3. APIキーはブラウザのlocalStorageに置く作りを指示した
4. 変換の指示文に機器ごとの役割設定を組み込みJSONで注意書きを返させた
5. GitHubの非公開リポジトリ経由でVercelへ公開した

アイデアを出してから約2時間11分で、3カテゴリ・全16種のOSに対応した変換サイトを本番公開できた。

公開までの最初のデプロイは開始から約1時間20分で終わった。

Claude Codeを本格的に使うと開発者1人あたり月200〜500ドル、時に2000ドルを超える費用がかかっていた。

質問に答えるため数千行のファイルを丸ごと読み込み、ほとんど使わない行まで課金される点が重かった。

1. 読み取りや定型生成を安いGemini 2.5 Flashに回す2つのモードを用意した
2. bulk-readerで大きなファイルを読ませ必要な情報だけ箇条書きで返させた
3. code-writerでテストや設定の雛形を作りファイルへ直接書き込んだ
4. プラグインshuntで350行超のReadを止めcatなど抜け道も塞いだ
5. 編集や深い推論や安全性が絡むコードはClaudeに任せた

Javaのモノレポで4つの場面を比べたところ、bulk-reader経由のときのClaude側のトークン消費は平均で約90%減った。

ただし委譲1回につき10〜30秒かかり、要約には正確な行番号が残らないため編集は任せられない。

GitHubのコードをAIに触らせるならCodexを起動するしかないと思い込み、小さな修正でもエージェントの使用枠を減らしていた。

1. ChatGPTの通常チャットにGitHub連携をつなぎ対象リポジトリを読ませる
2. まず変更しないよう伝え影響範囲と依存関係を洗い出させる
3. 数ファイルならブランチ作成から修正とPull Request作成まで指示する
4. 過去記事を読ませて構成と文体をそろえMarkdownを直接追加させる
5. テストを何度も回す大規模な変更だけCodexへ渡す

通常チャットからブランチ作成やPull Request作成まで到達でき、この記事自体もCodexの作業環境を立ち上げずにリポジトリへ追加できた。

軽い変更を通常チャット側で処理する分、Codexなどが共有するエージェント枠を大きな開発に回せるようになった。

ChatGPTのチャットからnoteへ記事を投稿するMCPを作ったが、APIが通るだけでX投稿が普通のリンクカードになったり、画像を差し替えたつもりが公開ページに反映されないといった問題が続いた。

1. 利用者の目的から逆算し本文作成から公開反映までの完了条件を置いた
2. URLを判定する。X/Twitterのstatus URLは埋め込みで登録する
3. それ以外は外部記事カードとして登録し分けた
4. 生成画像は公式画像と見比べて人が監査しNGなら再生成する
5. 公開後はdetail APIで公開状態と画像の反映を検証した

HTTPの2xxではなく公開後の表示状態を成功条件にしたことで、表示が壊れたまま完了とみなす事態がなくなった。

再起動の判定も45秒のhealth監視だけで失敗と決めず、タスクの稼働とポートのListenと/healthの応答を分けて見るようにした。

電子請求書発行システム「楽楽明細」の新オプションを、実装に使える期間が1か月弱という条件で12機能ぶん作る必要があった。

要求仕様書は例外系や受け入れ条件が足りず、そのままAIに渡せる粒度ではなかった。

1. 決めた仕様をClaudeでプロトタイプ化し40社に見せて機能を約30%削った
2. 要件をEARS形式で1アクション単位に分け例外パスも書いた
3. kiro（cc-sdd）でspec化しエージェントに読ませた
4. Codexを主軸にgit worktreeで機能ごとに複数セッションを同時に走らせた
5. 一次レビューをGitHub CopilotとClaude Codeで出し人が二次で確認した

4月7日の開発決定から5月末リリースと実質2か月未満で出せた一方、12機能を1本のプルリクにまとめたため変更ファイルは700超、サーバーサイドのレビューは全量確認に5営業日かかった。

実装方針を決めきらなかったため同じ指摘を機能の数だけ受けた。

既製の基板4枚をつないだ6キーのマクロパッドは動いたが、もっと薄く小さくするには専用基板が要った。

自分は基板設計の専門ではなく、手作業でゼロから起こすのが難しかった。

1. EasyEDA ProのAPIにJavaScriptを投げAIから基板を操作する
2. 回路図と配置を作らせトークン切れでClaudeからGrokへ交代する
3. 部品41個・パッド214個・配線120本を突き合わせる監査を書かせる
4. オートルータが動かないため自前のグリッド探索ルータを書かせる
5. Codexに引き継ぎコストに曲がり回数とビアを入れる修正をさせる

Claudeのグリッドルータが引いた722本・105ビアの基板は、Codexの書き直しで151本・33ビアになった。

探索時間はCPUで6分半・実時間10分かかるが、打ち切りを入れて実用の範囲に収めた。

Codexの5時間ごとの利用枠は最初のメッセージを送った時点から始まるため、開始時刻が日によってずれて作業時間と噛み合わなかった。

1. ChatGPTのMacアプリのWorkからScheduled Taskを作る
2. 毎日午前4時にPINGだけ返す軽い指示を登録した
3. 実行はNew chat each runにして会話を引き継がない形にする
4. モデルはGPT 5.6 Luna、ReasoningはLightを選ぶ
5. 翌朝SettingsのUsageでリセット時刻を確かめる

翌朝のUsage表示では5時間枠のリセットが9:14 AMとなり、4時14分ごろに枠が始まったと推定できた。

PINGだけの実行だったため残量は100% leftのままで、目立った消費は見られなかった。

アプリを作るには開発環境の用意やサンプルデータの準備が必要で、興味はあっても試すところまで進みにくかった。

1. 業務で使うSharePointリストのサイトを開く
2. 列構成とデータを分析しダッシュボードを作るよう文章で指示した
3. HTMLファイルをSharePointに保存しリンクを返すまで指示に含めた
4. 出来上がった画面をプレビューで開き動作を確かめた
5. チャットで追加のグラフや配置の修正を頼んだ

指示から1分ほどでHTMLのダッシュボードが出来上がり、件数や対応状況のカードと一覧表、絞り込みが使える形になった。

キーワード検索はファイルビューアー上で文字入力がうまくいかず、動作の確認は人がやる必要があった。

MCPサーバーを増やした結果、認証トークンやCookieの期限切れ、ローカルサーバーの停止に気づけなくなった。

タスクを頼んだ途中で止まり、原因の切り分けに手間がかかっていた。

1. GA4など8種類以上のMCPサーバーを1つの設定ファイルにまとめる
2. 認証方式を4つに分け鍵の置き場所とログイン手順を決める
3. 作業開始時に各MCPの状態確認を1行のプロンプトで頼む
4. 副作用のない確認用ツールを順に呼び生死を一覧で返させる
5. 落ちていたものだけ人が再ログインやOAuthを取り直す

作業の途中でトークン切れによって止まる失敗がなくなった。

どのMCPが落ちたかがすぐ分かるため、再認証は1分以内で終わるようになった。

細かいバグ修正でも、エージェントに依頼して修正内容を読み、手元で画面を立ち上げて確認しPRを書くまでを毎回自分でやっていた。

実装自体はAIだけで終わる場面が多く、この一連の作業が手間になっていた。

1. CursorのダッシュボードでGitHub・Slack・NotionのMCPをつなぐ
2. environment.jsonとセットアップスクリプトの作成をエージェントに頼む
3. 依存導入と開発サーバー起動まで確認済みのPRをマージする
4. Automationのトリガーを公開チャンネルの絵文字リアクションに設定する
5. 指示文を前半は原因特定と修正、後半は検証と返信に分けて書く

修正ごとにブランチを取得して自分の環境で症状を確かめる手間がなくなった。

細かいバグへの対応がかなり速く回るようになり、動作確認の動画もPRに残る。

スキルシートを一度書くと見直さないまま面談を迎えていた。

自分では当たり前と感じている経験が書く価値のある強みかどうか判断しづらかった。

1. 採用担当者の立場で深掘り質問をさせる指示書を作る
2. スキルシートと自分の技術記事を渡して一問一答で掘り下げる
3. 聞き出した内容を書く価値があるかAIに判定させる
4. 数字や固有名詞を残して短くまとめさせる
5. AIが理解した内容を毎回確認してから次へ進む

定量的な成果の記載が1件、属人化を解消したエピソードが1件加わり、曖昧だった表現が実態に合う形に直った。

書面上は運用保守中心の印象に見えていることも分かった。

VS Codeを更新するたびに出るRelease Notesは分量が多く英語のため、読まずに閉じていた。

新機能や変更点を知りたいのに手が出しにくかった。

1. 使用中のVS Codeのバージョンに合う公式Release Notesを取得する
2. 原文をLanguage Model APIに渡し日本語の要約を作らせる
3. 要約をまず知っておきたい変更・便利になったところ・必要な人だけ・3行まとめに分けて表示する
4. バージョン更新時に要約作成を通知しコマンドパレットからも呼び出せるようにする
5. 気になった項目は公式のSourceリンクから原文を読む形にし全文翻訳はやめる

拡張機能Release Digest for Visual Studio Codeを作り、MIT LicenseのOSSとしてGitHubにソースごと公開した。

専用のAPIキーは不要で、拡張機能自体は無料で使える。

Bedrock Guardrailsが守るのはモデルの入出力だけで、エージェントがツールを呼んだときの引数や戻り値は検査されない。

公式資料にその記載はあるが、本当に個人情報がそのまま通るのか確かめられていなかった。

1. Web検索と顧客データ取得の2ツールを持つエージェントを組む
2. ブロック設定とマスク設定の2種類のガードレールを用意する
3. フックなしで4ケースを流し素通りするか確かめる
4. Strands Hooksで推論前・ツール実行前・実行後の3検査点を足す
5. 各構成で3回ずつ応答時間を測り検査点の範囲を決める

モデルが個人情報を応答に出さないケースではツールの戻り値が検査されずに通過したが、ツール実行後の検査点を足すと両ケースとも止まった。

検査点の追加でかかる時間は約2〜3秒増え、ベースライン約5.8秒に対して40〜50%ほど伸びた。

上位プランや無制限課金を並行して契約すると月3万〜5万円まで膨らみ、かといって無料枠だけでは上限にすぐ当たって手が止まっていた。

1. ChatGPTに雑なアイデアを渡し要件定義とタスク分解をさせる
2. 結果をspecs配下のMarkdownとしてローカルに置く
3. そのファイルをAntigravity無料枠に読ませ生成やGit操作を自律実行させる
4. Cursorのインライン補完でコードを仕上げGitHubへ送る
5. PR差分とテストログをClaudeに投げ分析とリリースノートを任せる

月額は合計で約9,000円〜10,000円に収まり、上位プランをまとめて契約した場合の約30,000円〜50,000円と比べて安く済んだ。

役割を4つに分けたことで一つのツールが制限に達しても作業が止まらなくなった。

PLCのラダープログラムを検索して要約する社内サービスを作ったが、プロンプトインジェクションや内部情報の漏れといったAI特有の危険がどこにあるか分からなかった。

安全対策をどう検証すればよいかも手探りだった。

1. ソースコードと機能を調べリスク一覧を作る
2. 影響の大きさと起こりやすさの2軸で整理する
3. 攻撃の筋書きを書き疑似攻撃を実施する
4. 防御あり・なしで攻撃の成否を比べる
5. しきい値やポリシーを調整し報告会で共有する

不適切な出力や内部情報の露出など3種類の弱点が見つかり、そのうち2種類に対して高い検知性能を確認した。

通常利用での誤検知率は1.7%にとどまった。

攻撃の見逃し率は4.7%で評価にかかる時間も100ミリ秒以下となり、本番導入が決まった。

全社員にClaudeのTeamプランを配って個人の作業は速くなったが、各自が書いた手順書やスキルが個人の環境に閉じたままで会社の資産にならなかった。

さらに社員それぞれが業務アプリを動かすには保存や定期実行のできる本物のサーバが必要だった。

1. Claude Codeに切り替え1つのGitリポジトリへ文書とスキルを集約する
2. members/とteams/のディレクトリを作り個人の手順書を共有資産にする
3. アプリをCloudflareのWorkers for Platformsの上に置く
4. エージェントのコードは必ずPR経由で反映し履歴と巻き戻しを残す
5. 非エンジニアにはPRで確認用URLが出ることとマージで本番反映の2点だけ教える

非エンジニアが指示してClaudeが書いたアプリが、エンジニアの作るものと同じ厚みで本番を回すようになった。

エンジニア1人で作った基盤を5ヶ月運用し、社外APIの登録は40を超えた。

請求サービスの開発で実装を自動化しようとしたが、速くなったのは個人の作業だけでチームに残る資産が積み上がらなかった。

暗黙知が多く、実装レビューの指摘も減らないままだった。

1. cc-sddを土台に設計書をDB・ドメイン・API・その他の4つに分ける
2. 工程ごとに命名規則やテスト実装ガイドなど社内ルールを読ませる
3. AI向けのdesign.mdとは別に人が読むHTML設計書を作る
4. 仕様の分割や事前調査など独自スキルを足して43スキルにした
5. PRコメントとIssueを集め繰り返す指摘をWikiにためる

設計書をレイヤーに分けたことで大きな影響が出るDB設計を早く見られるようになり、手戻りが減った。

一方でWikiには約700件たまったがスキルへの昇格は20件ほどで、週1のサイクルはまだ回しきれていない。

社内のAIアシスタント基盤はWebのチャット画面しかなく、回答を手でコピーしてエディタに貼る手間がかかっていた。

ファイルの取り違えも起きやすかった。

1. 社内AI基盤のSDKを包むクライアントを自作する
2. CLI版とStreamlit版で同じロジックを共有させる
3. キーワードに関係するソースは全文添付し他はファイル名だけ渡す
4. 返ってきたコードは差分を出しy/Nで人が承認する
5. 上書き前に.bakを作りパスを二段階で検証する

チャットから承認を挟んでローカルのコードへ反映するまでを一つのツールでできるようになった。

先頭8KBだけを渡していた頃に起きた、実在しない関数を断定するAIの誤った説明も、渡し方を変えて減らせた。

AIに実装を丸ごと任せると、最後の確認が重くなり中身を理解しないまま進んでしまう。

知らない設計手法のコードが出てきて読むのに時間がかかっていた。

1. インターフェースとクラスの箱を自分で作る
2. 責務や入出力とエラー時の動きを決める
3. その設計をAIにレビューさせ抜けを自分で直す
4. メソッドの中身と別案をAIに実装させる
5. コードを読み境界値と依存とセキュリティを確認する

1日かけていた実装が10分ほどで終わることもあり、PR数は2年前の10倍ほどになった。

一方で設計とレビューにかける時間は以前より増えた。

自作の監査プロンプト集が拠り所にするセキュリティ基準は、版が次々と入れ替わる。

9日前に一次情報で全項目を確認したのに、OpenSSF OSPS Baselineの新版が公開4日後の時点で反映できておらず、人手で追い切れないと分かった。

1. 基準の現行版や供給網など9つの切り口に分けて並列で調べさせる
2. 修正案はJSON Schemaで形を決めて出させる
3. 置き換える現在の文と修正後の完成文をセットで返させる
4. 事実性を見る役と決まり違反を見る役の2つに別々に反証させる
5. keep/modify/dropで判定しどちらかがdropなら採用しない

修正案132件はそのまま採用31件、直して採用91件、棄却10件になった。

実在しない事故名を根拠にした案とコマンド挙動の誤説明がそれぞれ1件ずつ見つかり、片方の検証だけなら通っていた。