利用率 100% 達成 ! Amazon Bedrock を活用した生成 AI の開発組織への導入
2025-10-02 | Author : 松舘 快 (株式会社Techhouse)
はじめに
こんにちは、株式会社Techouse でノンデスクワーカー向け求人サービス「ジョブハウス」の開発に携わっているエンジニアの松舘 快です。
弊サービスは特に製造領域の採用支援においては国内最大級のサービスです。求人サービスの特性上、変化し続ける転職市場やユーザーニーズに迅速に対応するため、機能開発と効果検証のサイクルを素早く回していくことが非常に重要です。 そのため開発組織全体の生産性向上は重要な課題であり、昨今の AI の発展はその解決策として注目度の高いトピックでした。
そんな中で私たちの開発チームでは、Amazon Bedrock と Cline を活用した仕組みを構築し、エンジニアの AI 利用率 100 ％ を達成しました。
本記事では、現場での AI 活用を「仕組み」として根付かせるために私たちが行った具体的な取り組みを共有します。 AI の導入や組織への浸透に悩む方に参考になる記事になっておりますので、ぜひご一読ください。
builders.flash メールメンバー登録
builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。
背景と課題
取り組みの紹介の前に、課題を正しく認識する所から始めましょう。そもそも現場での AI の利用が浸透しないのは何故なのでしょうか ?
弊社では毎年 AWS re:Invent に現地参加するなど最新技術のキャッチアップを積極的に行っており、有用な技術は迅速に社内へ展開する文化があります。その例に漏れず、AI についてもトップダウンの意思決定により、早期に全エンジニアの利用環境が整備されました。
しかし、このように方針が示され、利用環境が整えられたにも関わらず、現場での AI 活用は簡単には進みませんでした。おそらく、「ライセンスは用意したのに、現場で利用が浸透しない」「有効な活用方法が蓄積されない」といった同様の課題を抱えている企業も多いのではないでしょうか。
組織ごとに原因は様々かと思いますが、私は以下の 3 つの課題に分解できると考えています。
3 つの課題
課題 1 : 期待する精度を出すには、高品質なコンテキストが不可欠
現在広く普及している生成 AI は、その多くがチャットによる対話形式です。利用者は自身の要求を AI にチャットで伝える必要がありますが、実はこれが非常に難しいタスクです。
LLM の能力は、過去のデータから類推して次の単語を予測することに基づいています。そのため、「一般的な正解」は得意でも、プロジェクト固有の事情を汲み取った「最適な解」を導き出すことはそのままではできません。プロジェクトの内情に則した適切なアウトプットを得るためには、その都度、以下のような固有のコンテキストをタスク毎に言語化して伝える必要があります。
- QA 項目書の作成 : 「この機能とこの機能は密結合だから、重点的にテストすべき」といった勘所
- 実装やコードレビュー : プロダクトが持つ独自のコーディング規約や、推奨される実装パターンといった、明文化されていないチームのルール
このようなコンテキストの中には明文化されていないものも多く、開発者がこれまでの経験の中で無意識に認識している事も多いかと思います。「普段無意識に認識していること」を正確に言語化し、AI への指示に落とし込む作業は困難です。この部分は要件定義・仕様・設計などのドキュメンテーションの難しさに通ずる部分があるかと思います。このコンテキストの質が、AI のアウトプットの精度に直結してしまうのです。このコンテキスト伝達がうまくいかなかったり、そもそもその必要性を認識できなかったりすることで、「生成 AI は使えない」という結論に至ってしまうケースも多いのではないでしょうか。
課題 2 : 高品質なコンテキストの構築には手間がかかる
仮にコンテキストを言語化できたとしても、次の課題が待ち受けています。それは、その作業が「非常に面倒」であるという点です。
精度の高いアウトプットを求めて、毎回詳細な背景情報や長文の指示をチャットで入力するのは、現実的ではありません。この手間が利用のハードルを上げ、結果として試してみたものの、面倒さが勝ってしまい億劫になる、というのもよくあるパターンかと思います。
課題 3 : 利用ノウハウが共有されず、組織的にスケールしない
これまで述べてきたように、生成 AI をうまく使える人と使えない人の差は「プロジェクト固有のコンテキストを、いかにうまく AI に伝達できるか」というスキルに集約されます。しかし、この重要なノウハウは組織内で共有されにくい、という難点があります。
なぜなら、その試行錯誤のプロセスは、個人のチャット履歴という閉じた作業空間に留まってしまうからです。優れたアウトプット (ドキュメントやコード) を目にすることはあっても、そのアウトプットが「どのように生み出されたか」という過程は不可視のままです。
この「利用方法のサイロ化」が、個人のスキルを属人化させ、組織全体でのスキル向上を妨げます。 結果として、一部の「うまく使える人」だけが利用し続け、組織全体の利用率が頭打ちになるという課題に繋がります。
この 3 つの課題を、私たちは Amazon Bedrock と VSCode 拡張機能の AI コーディングエージェント Cline を組み合わせた仕組みにより解決しました。以降のセクションでは、Amazon Bedrock の選定理由とこの仕組みの具体的な内容を解説します。
なぜ Amazon Bedrock を選んだのか
はじめに、数ある AI サービスの中から Amazon Bedrock を選定した理由を説明します。
Amazon Bedrock を選定した一番の理由は、「エンタープライズ水準の高度なセキュリティを確保できる」点です。企業が生成 AI を導入する上で、セキュリティは避けては通れない最重要課題であるといえます。特にエンタープライズ企業のお客様を数多く抱える私たちにとって、セキュアな AI の利用は選択肢ではなく必須要件でした。
Amazon Bedrock 及び AWS は、この要件を満たすセキュリティを提供してくれます。 具体的には、以下の 2 点が決定打となりました。
1. モデルとデータのプライバシー保護
Amazon Bedrock では、入力したプロンプトやデータが、基盤モデルの学習に利用されることはありません。 機密情報やソースコードを安心して入力できるこの仕様は、ビジネス利用における大前提です。
2. AWS セキュリティ基盤の利用
Amazon Bedrock は AWS のサービスの一つであるため、AWS の提供する堅牢なセキュリティ基盤をそのまま適用できます。
- アクセス管理 : AWS IAM (Identity and Access Management)を用いて、ユーザーやロールごとに API の利用権限をきめ細かく制御できます。
- データ暗号化 : 保存されたデータは AWS KMS の鍵で暗号化され、物理的なセキュリティも AWS のデータセンター基準で保護されます。
- 監査と監視 : AWS CloudTrail や Amazon CloudWatch と連携し、API の利用状況の監査や監視も容易です。
このように、私たちが使い慣れた AWS の高いセキュリティ水準を AI 活用にも適用できる点は、他のサービスにはない大きな魅力であり、技術選定の決定打となりました。
また、他にも以下のポイントは Amazon Bedrock の選択を後押しするファクターになりました。
Amazon Bedrock 選択のポイント
モデル選択の柔軟性
Amazon Bedrock では、バックエンドで利用する LLM のモデルを自由に選択することができます。現在 LLM の開発は過渡期にあり、様々な特徴と優位性を持つモデルが頻繁にリリースされています。そのような環境変化に柔軟に追従し特定のモデルへのロックインを避けるため、Amazon Bedrock の柔軟性は魅力の一つでした。
既存環境との親和性
私たちのサービスは既に AWS 上に構築されており、エンジニアも AWS のサービスに精通しています。Amazon Bedrock であれば、既存の AWS エコシステムとシームレスに連携でき、導入の手間を最小限に抑えられる点も大きな魅力でした。
「仕組み」による解決
次に、先程提示した 3 つの課題を解決した仕組みについてご紹介します。
AI の利用を組織全体に広げていくにあたり、考えられるアプローチはいくつかあります。 例えば、「勉強会」や「ペアプログラミング」といった人的なナレッジ共有も有効な手段です。これらは継続的に行うべき重要な活動であることは間違いありません。しかし、これらの施策は熱意ある個人の努力に依存しがちで、運用コストも高く、持続性という観点ではどうしても属人化から逃れられないという側面があります。
そこで私たちは、人的な努力を補完し、より持続可能でスケールする 「仕組み」による解決を目指すことにしました。
この「仕組み」が満たすべき要件を、先ほどの課題に沿って考えてみましょう。
まず解決すべきは、最も根深い課題である「利用ノウハウの属人化」です。優れたユーザーの AI 活用術を、AI への関心度合いに関わらず誰もが再現できること。私たちはこの要件を「標準化」と定義し、仕組みの土台に据えました。個人に閉じていた AI の利用方法を、誰もが使えるスタンダードな仕組みとして提供することを目指しました。
次に、その標準化されたノウハウを、いかにして現場で負担なく使ってもらうか。ここで課題 1「コンテキスト伝達の難しさ」と課題 2「入力の手間」が立ちはだかります。この 2 つの課題を解決するのが、第二の要件である「簡易化」です。標準化された高品質なコンテキストを、ユーザーが「考えずとも」「瞬時に」呼び出せるようにすることで、利用のハードルを劇的に下げます。
とはいえ、この「標準化」と「簡易化」を全ての業務にいきなり適用するのは現実的ではありません。そこで私たちは、最初のステップとして「多くの開発者が恩恵を受けられ」かつ「AI を導入しやすい」プロセスに的を絞りました。
今回は、その両方を満たす業務として「コードレビュー」を例に取り、具体的な取り組みをご紹介します。
1. ワークフロー化による「標準化」
まず、課題 3「利用ノウハウの属人化」を解決する「標準化」への取り組みとして、私たちは業務のワークフロー化を行いました。これは、「AI の利用方法は人によって様々だが、特定の業務に絞れば、優れた手順はある程度定型化できるはず」という着想に基づいています。
この定型化された手順を「ワークフロー」としてファイルに定義し、AI に実行させるのです。AI はファイルに記述されたワークフローに忠実に従うため、実行するユーザーのスキルに依存せず、質の高い業務を再現できます。
弊社では、コードレビューを行うワークフローとして、このようなドキュメントを .cline_bank/workflow/ 配下に実装しています。
このように、詳細な作業内容をワークフローとして明文化することで、誰が実行しても AI によるサポートの質が均一になり、スキルの属人化を防ぎます。
2. 「簡易化」による利用ハードルの低減
次に、課題 1「コンテキスト伝達の難しさ」と課題 2「入力の手間」を解決する「簡易化」への取り組みです。これを「コマンド化」と「コンテキストのモジュール化」の 2 つのアプローチで実現しました。
2-1. コマンド化 (呼び出しの手間の削減)
「簡易化」の第一歩は、定義したワークフローをいかに簡単に呼び出すか、という入力の手間を削減するための「コマンド化」です。
私たちは、ワークフローの実行方法自体もルールとして定義し、開発者がまるでシェルコマンドのようにワークフローを呼び出せる仕組みを構築しました。具体的には、定義したワークフローを特定のパスに配置し、以下のようなルールファイルを AI に読み込ませます。
このファイルは、Cline がタスク開始時にデフォルトで読み込む .clinerules/ ディレクトリ配下に、workflow という名前で配置します。この仕組みにより、開発者はコンソール上でファイル名を指定するだけでワークフローを実行できます。エディタの補完機能も活用できるため、少ないタイプ数での呼び出しが可能です。何より、この体験は開発者にとって馴染み深いシェルコマンドの実行に近く、AI 利用の心理的なハードルを大きく下げます。
2-2. コンテキストのモジュール化 (思考と入力の手間の削減)
「簡易化」の第二歩は、高品質なコンテキストを注入する思考コストと入力の手間を削減する「コンテキストのモジュール化」です。
なお、ここで言うコンテキストとは、あくまで特定の「ワークフロー」における品質基準やルールを指します。プロダクト全体の背景知識といった、より広範なコンテキストの与え方については、多くの AI コードエディタが推奨する構成がありますので、そちらをご参照ください。
例えば、コードレビューにおいて「このデザインパターンを遵守してほしい」「これらの観点を重視してほしい」といった、プロジェクト固有のポリシーがワークフローのコンテキストに当たります。
私たちは、このコンテキストをワークフロー定義ファイル自体に記述しておくことで、AI がその規範に則ってタスクを実行するようにしました。
※文面の都合上省略していますが、実際には細かく注意点やテンプレートの内容が記載されています。
レビューの観点や返答フォーマットといったコンテキストをワークフローに内包させることで、ユーザーは都度詳細な指示を考えたり入力したりする必要がなくなります。これにより、手間を省きつつ、常に精度の高いアウトプットを安定して得ることができるのです。
副次的な効果
これらの「標準化」と「簡易化」の取り組みにより、AI 利用のハードルは劇的に下がり、多くの開発者がその恩恵を手軽に受けられるようになりました。
しかし、導入効果はそれだけではありませんでした。特に重要だったのが、ワークフローの定義をコードと共にリポジトリで管理した点です。これにより、コードレビューのプロセス自体が、開発者にとって馴染み深い「Pull Request」による改善提案の対象となりました。
結果として、開発者から自発的にワークフローを改善する Pull Request が提出されるようになり、チームが自らの開発プロセスを自律的に改善していく「自己組織化」が促進されたのです。
これは単なるツール利用の促進に留まらず、チームの主体性を引き出し、継続的な改善サイクルを生み出す「自律的な仕組み」の構築に繋がりました。
定量的な評価
最後に、現在の開発チームにおける AI 利用状況について、アンケートを実施したので公開します。
AI の利用頻度
まず AI の利用頻度です。結果を見ると、94.4% のエンジニアが「毎日利用する」と回答しました。 残りの 5.6% も「週に 2 ~ 3 回利用する」と回答しており、チームの全員が日常的に AI を活用していることがわかります。
生産性への影響
次に、生産性への影響です。「生成 AI 使用前と比較した開発スピードの変化」について、1 (逆に効率が落ちた) ~ 10 (大幅に向上した) の 10 段階で評価してもらいました。
回答者の半数 (50%) が、最高の評価である「10」を付けていることがわかります。 さらに、評価「6」未満のスコアを付けておらず全ての開発者が、開発スピードの向上を実感していることがわかります。
今回紹介した取り組みが要因とは限りませんが、少なくとも「標準化」「簡易化」の取り組みが AI 利用のファーストステップをアシストし、結果的にチーム全体の利用率の底上げに繋がった事を実感しています。
おわりに
本記事では、生成 AI の利用率を 100% に引き上げた「仕組み」について、その背景にある課題から具体的な解決策、そして組織にもたらされた変化までをご紹介しました。
重要なのは、単に便利なツールを提供するだけでなく、「標準化」によって属人性を排除し、「簡易化」によって利用のハードルを極端に下げることです。 さらに、その仕組み自体を開発プロセスに組み込むことで、チームが自律的に改善を回していく文化が生まれます。
開発組織への AI 導入でお困りの方は、今回ご紹介した「コードレビュー」のような、身近で効果の大きい業務からワークフロー化を試してみてはいかがでしょうか。 この記事が皆さんの組織における AI 活用への一助となれば幸いです。
筆者プロフィール
松舘快(@aki_pin0)
株式会社テックハウス エンジニア
2024 年 4 月に新卒で Techouse株式会社へ入社。人材プラットフォーム事業部のバックエンド/インフラエンジニアとして、主に AWS 基盤におけるシステム開発とパフォーマンス改善に取り組んでいます。
