社内の勉強会（WG）で、生成AIの最新動向と、それを実務にどう生かすかを話し合いました。本記事では、その中から特に役立つと考えた3つのテーマをご紹介します。1つ目はAIの利用コストを抑えるプロンプトの組み立て方、2つ目はAIエージェントを安全に動かすための「止める仕組み」、3つ目はAIを中心に据えた開発の進め方です。
1. プロンプトキャッシュを意識して、コストと待ち時間を減らす
プロンプトキャッシュとは
生成AIをAPI（プログラムから呼び出す窓口）で使うと、入力した文字量に応じて料金がかかります。この量は「トークン」という単位で数えます。プロンプトキャッシュとは、毎回同じ内容の指示文を送る場合に、その部分をAI側で再利用する仕組みです。キャッシュが効いた部分は料金が割り引かれ、応答までの待ち時間も短くなります。
WGでは、この仕組みを意識してプロンプトを組み立てると、該当部分のトークンコストを大きく下げられることを確認しました。最近はAPIだけでなく、チャット画面や開発環境でもキャッシュによる割引や使用量が見えるようになっています。ただし、使用量の表し方はサービスによって違います。使った割合が増えていく表示もあれば、残りが減っていく表示もあるため、見方には注意が必要です。
変わらない要素はプロンプトの先頭に集める
キャッシュを効かせるコツは、毎回変わらない要素（システムとしての決まりごと、共通の指示、ツールの定義など）をプロンプトの一番前にまとめることです。毎回変わる内容（ユーザーの質問や今回のデータ）はその後ろに置きます。
Claudeでは、システムの前提を書く claude.md や、ツールの使い方を書く skill.md のように、固定の情報をファイルで渡す使い方があります。こうした固定情報を先頭に置く設計を徹底すれば、キャッシュに当たる割合が上がり、運用コストを抑えられます。
モデルは用途で使い分ける
WGでは、モデルの使い分けも話題になりました。最近は、安価でも精度の高い軽量モデルが増えています。エンジニア以外の方が使う定型的な処理には軽量モデルを、複雑なエージェント処理には上位モデルを、という使い分けが有効だという意見が出ました。
また、モデルは次々と新しくなります。そこで、Difyのような、画面上で処理の流れを組み立てられるツールを間に挟む方法も検討しました。こうしておくと、処理の流れはそのままで、使うモデルだけを差し替えやすくなります。
2. AIを「止める仕組み」を先に考える
ハーネス（制動機構）という考え方
AIエージェント（人の代わりに複数の手順を自分で進めるAI）の能力が上がるほど、想定外の動きをしたときの影響も大きくなります。WGでは、AIの暴走を防ぐハーネス（安全帯・制動の仕組み）の重要性について議論しました。AIが意図しない動きをした例が報じられたことも話題になりました。
参考として取り上げたのが、最新のフラッグシップモデルに導入された3段階の防御です。考え方は自社でAIを組み込むときにも応用できます。
- 実行前のチェック：指示や目的が妥当かを確かめる
- 実行中の隔離：サンドボックス（本番環境から切り離した実験用の環境）の中で動かし、システムへの直接の影響を防ぐ
- 実行後の出力チェック：決められた範囲を越えた動きや、不適切な出力がないかを最後に確かめる
つまずきの原因は人間の側にもある
WGで印象的だったのは、「AI活用の一番の妨げは、AIの能力の限界ではなく、人間側のミスや監視の負担ではないか」という問題提起です。複数の作業を並行していると、疲れから別の画面に指示を入れてしまうことがあります。また、AIの動きを人が常に見張り続けると、時間と気力を消耗します。
これを仕組みで減らす設計として、次のような考え方が挙がりました。
- 人との窓口を1つにまとめる：人は取りまとめ役のAIとだけやり取りし、そのAIが作業を分けて専門のAIに割り振る。誤った場所に指示を入れるミスを構造的に防ぎます。
- 作成とレビューを別のAIに分ける：作業したAIとは別のAIが、成果物を自動で確認します。
- ログを残す：どのAIが、いつ、何をしたかをファイルに記録し、後から確認（監査）できるようにします。
- スマートフォンから承認できるようにする：AIが人の許可を待って止まらないよう、外出先からでも承認できる仕組みを用意します。
- 使う人の習熟度に合わせる：初心者には答えだけでなく背景の説明も返し、成長を助けます。
AIの専門役割は重ねず、それぞれの得意分野を「尖らせる」ことも大切だという意見も出ました。
3. ターミナルで完結するAI主導の開発フロー
開発の進め方については、VS Code（コードエディタ）、Claude Code（ターミナルで動くAIの開発支援ツール）、GH CLI（gh：GitHubをコマンドで操作するツール）を組み合わせたやり方を共有しました。開発者がターミナルで課題や変更内容を伝えると、AIが次の流れを進めます。
- 既存のIssue（課題の記録）を検索し、同じ内容がないかを確認する
- 重複がなければ、新しいIssueを起草して登録する
- ブランチ（作業用の枝分かれ）を作り、コードを修正する
- プルリクエスト（変更の取り込み依頼）を作成する
この流れはブラウザを開かずに最後まで進められます。画面の切り替えや手作業の転記が減り、作業の抜け漏れも防ぎやすくなります。WGでは、このやり方をチームの標準にしていくことを確認しました。
ルールは段階に合わせて柔軟に
あわせて、チーム専用の非公開のGitHub環境を用意し、コードやプロンプトのノウハウを安全に集める運用も話し合いました。ルールは、開発の段階に合わせて変えます。
- 個人の検証や実験の段階では、スピードを優先し、メインブランチへの直接の反映も認める
- 複数人で使う中心的な資産や、商用化の段階では、ブランチとプルリクエストを通して相互レビューする
最初から厳しいルールにすると、試行錯誤の勢いが落ちてしまいます。一方で、共有する資産には確認の仕組みが必要です。この両立がポイントです。
まとめ
今回のWGで見えてきたのは、AIの性能そのものだけでなく、周りの設計で成果が大きく変わるということです。固定要素を先頭に置いてキャッシュを生かす、実行前・実行中・実行後のチェックで安全を確保する、人のミスが起きにくい窓口や記録の仕組みをつくる、開発の流れをAIとツールの連携で一本化する。どれも、規模を問わず取り入れやすい考え方です。当社では引き続き、こうした知見を実際の開発に生かしていきます。
技術ブログのほかの記事