生成AI推進担当に聞く、AI駆動開発を現場に根付かせる実践ノウハウ ── ツール選定・チーム展開・ハルシネーション対策まで

はじめに
プロフィール
ツールの使い分け：マルチモデルで弱点を補う
チームへのAI駆動開発展開：「使ってください」だけでは定着しない
仕様駆動開発の実践：小さく作って積み上げる
ハルシネーション対策：公式情報を必ず参照させる
スキル化とSuperpower：繰り返し作業はすべて自動化する
出力レビュー：AIらしさを除去する
まとめ：針生さんの実践ノウハウ早見表
おわりに

はじめに

こんにちは！クロスインダストリー第1本部クラウドモダナイズ課のローです。

アプリケーションサービス本部（AS本部）でAI駆動開発の社内推進と外向けサービス展開を担っている針生泰有（はりうやすとも）さんに、実践的なノウハウをインタビューしました。

針生さんのバックグラウンドや日常の働き方については、サバワク記事をご覧ください。本記事ではエンジニアが実践で役立てられる技術的なノウハウに絞ってお伝えします。

sabawaku.serverworks.co.jp

プロフィール


氏名	針生泰有（はりうやすもと）
所属	アプリケーションサービス本部部付
主な活動	AI駆動開発の社内推進、サービス企画、外向けウェビナー登壇、社内勉強会
関心領域	AI-DLC、仕様駆動開発、Claude Code、Kiro、Amazon Bedrock AgentCore

ツールの使い分け：マルチモデルで弱点を補う

― 普段どのようにAIツールを使い分けていますか？

Claude Code、Codex、Gemini、Kiroをそれぞれ役割に応じて使い分けています。

Claude Codeがメインです。コード生成・アプリケーション開発向けの精度が高く、日本語でもフレンドリーに幅広く回答してくれるのが気に入っています。

Codexはコードレビューに特化して使っています。Claude Codeで生成したものをCodexに二重チェックさせる運用で、重箱の隅まで細かく見てくれるので、サブとして利用しています。

Geminiは検索精度とレスポンス速度が高いので、ちょっとした調べ物・情報収集に使っています。

Kiroは主にCLIを利用していて、AWSサービスの機能を押さえたいときや、お客様対応の技術確認に活用しています。

ポイント： 1つのモデルで完結させようとせず、「生成はClaude Code → レビューはCodex」のように役割を分けることで、各モデルの弱点をカバーしています。

チームへのAI駆動開発展開：「使ってください」だけでは定着しない

― AS本部でAI駆動開発を推進するにあたって、最初に取り組んだことは何でしたか？

まずガイドラインの整備から始めました。ただ、ガイドラインを作っただけでは実際には定着しません。「使ってください」と言うだけでも導入はなかなかされない、というのが正直な実感です。

サーバーワークスはお客様の環境での開発が多く、気軽に試せない案件も少なくありません。そこで自分自身も案件に入りながら、チームと一緒に1歩ずつ進めていく形にしました。

― 現在の体制を教えてください。

現在は各課にAI駆動開発推進リードエンジニアを1名ずつ配置する仕組みを構築しました。部付の立場だと現場の細かい状況が見えにくいため、同じ課内に「AI駆動開発の相談役」を置くことで、情報共有と定着速度を上げています。いわゆるAI CoEに近い組織構造です。

その前段階として、AI-DLC（AI-Driven Development Lifecycle）や仕様駆動開発の基礎を全社向けの勉強会で共有し、共通言語を作ることから始めました。

チーム展開の流れをまとめると：

ガイドライン整備（利用ルール・セキュリティポリシー）
有識者が案件に同行し、実際の開発で共に試す
各チームにAI駆動開発リードを配置（AI CoE的構造）
定期的な勉強会でナレッジを横展開

仕様駆動開発の実践：小さく作って積み上げる

― AI駆動開発で失敗しないためのコツはありますか？

大枠だけを伝えて「こういうアプリを作って」と指示しても、思った通りのものはできないので、精度を高めるには、次のアプローチが有効かと思います。

まず何も肉付けされていないシンプルなベースアプリを生成させる
動作確認をする
必要な機能を1つずつ追加していく

最終形を一気に作ろうとすると仕様の確認が複雑になり、意図とのズレが生じやすくなります。小さく積み上げていく方が仕様も読みやすく、修正コストも下がります。これは仕様駆動開発（Spec-Driven Development）の基本的な考え方とも合致します。

ハルシネーション対策：公式情報を必ず参照させる

― AIの誤回答（ハルシネーション）への対策を教えてください。

出力されたものは一旦すべて疑うことを前提にしています。具体的には以下の3点を実践しています。

① AWS MCP Server で公式情報を取得する

AWSに関する質問は、AWS MCP Server を通じてAWSの公式ドキュメントベースの情報を取得させます。モデルの学習データに依存させず、ソースを公式に固定することでハルシネーションのリスクを大幅に下げられます。

aws.amazon.com

② Context7 MCP でライブラリの最新情報を参照させる

ライブラリやフレームワークの仕様はバージョンによって変わります。Context7 MCPを使うことで、常に最新のドキュメントを参照させる運用にしています。

③ Codex でクロスレビューする

Claude Codeで生成したコードや文章は、Codexに別途レビューさせます。同じLLMで自己チェックするのではなく、異なるモデルで検証することで見落としを減らせます。

スキル化とSuperpower：繰り返し作業はすべて自動化する

― 最近特に効果を感じているAI活用の方法は？

「スキル化」です。ルーティン作業や「これは汎用的に使えそう」と感じた手順はすべてスキルとして定義します。ブログ作成のワークフローもスキル化していて、使うたびにブラッシュアップしています。1回作ったら終わりではなく、実際に使い続けながら自分オリジナルのスキルとして育てていくイメージです。

あわせて「Superpower」プラグインも活用しています。Superpowerはタスク実行前にブレインストーミングとプランニングを自動で行うプラグインで、仕様駆動開発のアプローチに近い動きをします。いきなり実装させるのではなく、事前に「何を・どの順序で・どんな方針でやるか」を定義させてから動かすことで、アウトプットの精度と一貫性が上がります。

スキル化のサイクル：

実行してみる → 改善点を見つける → スキルに反映 → また実行してみる

このサイクルを回すことで、プロンプトとワークフローが徐々に自分の業務・文体・判断基準に合ったものになっていきます。

出力レビュー：AIらしさを除去する

― AIの出力をそのまま使うことはありますか？

ほとんどありません。特に対外的な文章や発言として使う場合は、「AI臭さ」を取り除く作業を必ず入れています。具体的には「自分ならこういう言い方はしない」という箇所を都度修正します。

AIが出力した文章は、自分の言葉として発信する際に人間のレビューを経ることが前提です。まずAIに出力させて、そこに自分なりのエッセンスと確認を加える、というプロセスが基本形です。

まとめ：針生さんの実践ノウハウ早見表

テーマ	実践内容
ツール使い分け	Claude Code（メイン）→ Codex（レビュー）、Gemini（調べ物）、Kiro（AWS）
チーム展開	ガイドライン → 案件同行 → 各チームにAIリード配置
開発方法論	仕様駆動開発：ベースから小さく積み上げ
ハルシネーション対策	AWS MCP Server・Context7 MCP で公式情報参照＋ Codex クロスレビュー
自動化	ルーティンのスキル化＋ Superpower で事前プランニング
出力品質	必ず人間がレビューし、AI臭さを取り除く

おわりに

「使ってください」だけでは定着せず、ガイドライン整備・案件同行・チームへのリード配置という段階的なアプローチで現場に根付かせてきた針生さん。ツール選定からハルシネーション対策、スキル化まで、すぐに実践できるノウハウが詰まったインタビューでした。

針生さんのAIとの向き合い方や日々の働き方については、ぜひサバワク記事もあわせてご覧ください。