Last updated: 2026/04/05

AI-Driven Development

AI利用の原則

1. セーフティファースト
   • 致命的な結果をもたらすような権限を決してAIに与えてはいけない
     • e.g., 機密情報の流出、重要なデータの破壊などに繋がる権限は最初からすべてシャットアウト
   • そのほかはリスクに応じた防御策を
     • 情報の流出リスクをオプションや契約、保険契約で担保するなど
     • 作業のリスクゼロを求めるとAI利用をあきらめるしかない。だがAI利用を避けること自体がビジネス上の巨大なリスクである
   • 安全が確保されているからこそ積極的に利用できる。セキュリティは邪魔者ではない
2. 十分なコンテキストの用意
   • 必要な情報やツールへのアクセスが良好な生成の土台
   • リスクを許容できる範囲内で上限いっぱいの権限を渡せるのが望ましい
3. 精度に応じたプロンプトの作りこみ
   • ちょっとした内容は思いついたままに聞けば十分。それでも今のAIなら十分な回答を返してくる
   • 高い精度が必要な作業はコンテキストエンジニアリングやプロンプトエンジニアリングを考えるといい
     • そしてできればプロンプトはSkillsなどの機能を使って使いまわす。何度もプロンプトを考えるのは大変なので
     • さらにボリュームもあるならAIエージェントとSpec Drivenで対応

コンテキストエンジニアリング（プロンプトエンジニアリング含む）

• 生成に必要な情報を十分渡し、ノイズ情報を極力減らす
  • 精度を上げ、コストを減らす最良の手段
• 気づきづらいノイズ源は最小限に
  • 自動挿入コンテキストに大量のノイズが含まれていることがある。そういうものを極力減らす。
    • 例えばClaude CodeのCLAUDE.mdと履歴。
• 巨大すぎるプロンプトが必要になるなら、タスクを分割して小さくする
• 基本は「してほしいこと」と「してほしくないこと」そして厳密にやるなら「明確な受け入れ条件」
• スクリプトやツールで済むものはそちらを使う
  • そのためのスクリプトやツールをAIに作らせればよい
• 指示を出す前に調査・確認する
  • 雑な指示で生成させたところで全部捨てるはめになる。私はそれで何度も捨てた
• 公式MCP, 公式プラグインなどは積極的に利用を
  • あれこれ自分で考えるより良質なものが早く手に入る
• 渡したプロンプトの再現性・トレーサビリティを確保する
  • なにも工夫しないとこうなる「もう一回同じ指示を出したくても出せない。なぜそうなったのかもわからない」
    • これでは途中から生成させなおすことができない
    • 生成されたものが指示通りか確認する術もない（指示が残ってないから）
  • どこでどう確保するかは腕の見せ所
    • リポジトリに保存、ログとしてのこす、Github Issueに残す、本当にいろいろある

開発体制の整備

• 開発ルールを整える
  1. 混乱防止: 混乱 -> e.g., リンターが複数ある、環境名がバラバラ、必要なテストが人によってあったりなかったりする、なんなら同じ人がやっててもそう
  2. AIの利用効率向上: 逐一指示しなくても「ルール通りにやれ」だけで済む
  3. 品質向上: 例えばフォーマッタ・リンター・静的解析の利用をルールで必須にするだけでも品質は底上げされる
• ワークフローも整える
  • 型通りにやればすむことは型通りにやる。同じタスクは同じ手法で処理する。
  • 都度都度やり方を考えるのは、それしかない時にやること
  • 作業手順、書式のテンプレートなど行えることはたくさんある
• 自動化・仕組化する
  • ルールを全部人間に守らせるのは大変。自動化・仕組化が望ましい
    • 最たるものはCI/CD。フォーマッタのかけ忘れなどはありえなくなる
  • 機械的に行えるのが一番確実だが、難しければAIにやらせる
    • 確実性はやや劣る点にだけ注意すれば十分使い物になる
  • 頻度が高い業務、ミスしやすい業務、認知負荷が高い業務はねらい目
• やりすぎ注意
  • 整備にかかるコストと見返りを常に天秤にかけるべき。
    • 2年に1度、30分で済む単純作業を1か月かけて自動化する合理的理由はない

Spec Driven

• そのメリットは 1)段階的な具体化による品質の担保 2)再現性 3)トレーサビリティ。デメリットは 1) 仕組みの構築が重い
  • 対極と言える手法はVibe Coding。手軽だが品質はまちまちで、もう一度同じことをしたくても難しく、なぜそうなったのかわからない
• AI駆動開発やるなら必須の技術
  • spec-kitがお手本
    • ただし汎用性を追求している分、そのまま自分のプロジェクトに当てはめて使うのが難しい。実務にはカスタマイズして使うことを推奨
• 実運用は総合力勝負になる
  • 開発体制の整備
  • 要件定義、設計、作業指示書などのドキュメント作成能力
  • 作成したドキュメントの管理能力
  • チーム利用を前提とした改善サイクルと横展開
  • AIエージェントの機能やCI/CDなどの自動化・仕組化
• 例えばIssueに要件を書き、その要件をClaude Codeに読ませて設計させてリポジトリに保存し、設計を元に作業指示書を作らせたあと実装する
  • これをClaude CodeのSkillsやAgentsを使いながら行うことになる
• 仕組みの構築が重いので少しづつ充実させていくのが現実的
  • AIを使っていても普通に数か月かかる

生成物の精度向上

• ポイントは「プロジェクトの頭で整え、末で保証する」
• してほしいことを形にするのがまず第一歩
  • 要望が固まっていないと何が正解かも決まらない。変数の書き方一つとっても、スネークケースで書いて欲しいのかキャメルケースで書いて欲しいのかを決めてないなら、AIはどっちでも書いてくるし、どっちも正解になる
  • 頭の中にあります、ではAIが参照できないので、形にする必要もある
    • これは具体的には、要件や開発ルールなど形で現される
  • 良好な生成をさせるための十分な情報を指示として渡す
• AI駆動開発も「システムの品質はテストの品質によって決まる」
  • AIの生成はランダム。品質もランダム。AIにチェックさせても、チェック品質自体がランダム。 -> どれほどプロセス構築を頑張ってもこの品質のばらつきの壁を越えられず、プロダクト品質に届かない
  • 信頼できるテスト（単体・統合・E2Eなど）で品質を保証するのが必須
    • AIにテスト実行 → 結果を元にAIに修正させるループ

Githubの活用

• 権限管理をしっかり行い、安全を確保し、その上でAIに好きにさせる
  • GitHubは権限管理をかなりきめ細かく行える
  • Fine-grained personal access tokensだけでもかなり頑張れる。AI専用アカウントも用意できるとさらに柔軟な設定ができる
• 権限管理は自動化を強く推奨
  • 確実に、素早く、漏れなく設定できる。
    • 手作業は一見楽に感じられても維持管理が大変
  • Terraform, API, etc, etc.
• 基本的にモノレポ推奨
  • AIに横断で作業をさせるのが楽なので
• Git本体はもちろん、Issue, PRも使うべき
  • AIに読ませるのが簡単

ガバナンス

• ポリシーの文書化
  • 使ってよい範囲を明示する
    • 全てのリスクを会社が引き取るのは危険すぎる。しかし何も決めずに「何かあったら使った人間の責任」では業務で使えない。落としどころと責任分界を決めておく
    • 使ってよいAIの範囲: 業務の性格によって決める。クラウドAIも可か？　委託含め自社管理のAI(e.g., AWSのBedrock)までか？　全面禁止か？
  • 禁止事項の明示
    • 機密情報の外部送信やAI学習利用の許可などに注意
  • 国立標準技術研究所（NIST）の「AIリスクマネジメントフレームワーク」（AI RMF）が参考になる（邦訳版）
• 著作権やライセンス上の問題解決
  • 妥当な権利帰属の取り決め: なにをどこまで保証するかの落としどころを決めておく。「“全"納品物の"全"著作権を譲渡する」のように過剰な条項はトラブルの元
  • 生成物の商用利用・再利用: 規約で禁止されていないか確認が必要
  • ライセンス汚染が問題となるOSSの利用: AIが勝手に使っていて気づかないリスクあり。スキャンを。
• コスト管理
  • 予算上限と利用額の監視
• 雑に禁止せず運用による工夫を
  • 機密情報とそうでもない情報が入り混じっていて分離もできないデータ群は、問題ない個所だけ別の場所に複製して使う
  • 権限や安全性の面でAIに全面的にゆだねることができないが、しかしAIをできるだけ使いたいワークフローは、ヒューマンインザループで対応する

ナレッジ運用基盤

• 正確な情報を残す。そして検索できるようにする
  • 検索しやすくする工夫も重要
    • 命名規則（表記ゆれの軽減）
    • タグの利用
• 作業記録は資産
  • それをもとにAIに調べさせたり分析させたりするのに使う
  • 人間にも有用
  • チケットドリブン + バージョン管理システム + 再現性・トレーサビリティの文化で実現
    • 楽なのはGithubとGithub IssueとPull Requestに作業を残すこと。CLIやAPI、権限管理の仕組みも充実しておりAIと組み合わせやすい
    • 文化とは、やったことをちゃんと記録するのを善とする意識付け、またはAIに記録を義務付ける共通プロンプト(e.g., CLAUDE.md)

AIモデル選定

• AIモデル自体だけでなくAIエージェントの使い勝手も重要
  • 今よく聞くのはClaude Code、Codex。次点でGemini CLIや自前でカスタムしたエージェント
• 定期評価もしたい
  • 月一で同じタスクをそれぞれに投げてみる程度でも十分
  • 評価・転換自体に多大なコストがかかる。頻繁な乗り換えは非合理的

組織的な展開

• 実際に使う。そして成果が出た仕組みを残す
  • 最初に「AIの使い方をMECEで推定してそれに応じた仕組みを標準化し～」などと一から演繹するのは無理筋
    • いわゆる過剰設計・オーバーエンジニアリングになる
    • そもそも再現性がない・標準化のコストに見合わない小さな業務も多々ある。こういうタスクは標準化自体が向いてない
• 効果的なものは標準化・共有資産化する
  • 使いまわせるテンプレートやワークフローも存在する。そういうものは標準化したほうがいい
    • やりすぎないことが大事。標準化するコストは多大である。目的は品質の底上げと効率化であり、支配・統制ではない
• 継続的に改善もする
  • .claude/もGitで管理してPR使いながら時折更新
  • もちろん追加もしていい
• 成果物や利用率の指標は遅行指標としてのみ使うべき。KPI（ノルマ）にしてはならない
  • AI活用の度合いは環境による影響が大きい。絶対評価に使うには雑過ぎる

TIPS

• 頻繁に使うコンテキストは英語化推奨
  • 日本語よりトークン効率が良いので。
    • 英語が苦痛でAIを使わなくなったら本末転倒なので、「出来れば」レベルの工夫
  • 頻繁に使うコンテキストの代表はCLAUDE.md

AI駆動開発ガイド

AI-Driven Development

https://www.tricrow.com/policies/ai-driven-development.html

この記事を書いた人

T.Nakamura

SRE | セキュリティ前提の設計・運用・監査対応(PCI DSS) | ドキュメント整備と仕組み化で開発・運用を整えます | AWS SAP / 日商簿記一級フォローはこちら