grasys 探索 Human-in-the-loop 做法，調整 AI 驅動開發流程以應對技術變化

2014年の創業以来、クラウドインフラの構築・運用から、クラウド上のアプリケーション開発・運用まで、エンタープライズ企業が抱える数億人規模の高トラフィックなビジネス基盤を強靭なインニアリングで支えてきた株式会社grasys。

同社の技術力は、IaC（Infrastructure as Code）を用いたインフラ構築と、アジャイルなアプリケーション開発の両領域で技術力を発揮しています。とくに昨今、生成AIの台頭により開発パラダイムが劇的に変化する中、同社はいち早くAIをワークフローの中核に据えました。

前回の「Policy as Code」を用いたインフラエンジニアリングに続き、今回は「grasys流AI駆動開発（AI-Driven Development⁠）⁠」に焦点を当てます。LLM（大規模言語モデル）のルーティング戦略から、AIへのセキュアな文脈（コンテキスト）共有、テスト駆動によるAIの暴走を防ぐテストハーネスの実装、そして組織としての「Human-in-the-loop（人間の適切な介在⁠）⁠」の在り方について、最前線で開発を牽引するCloud Development Sec. Chiefの品地哲弥氏に深掘りして取材しました。

AI駆動開発へのシフト⁠：定型コードからの解放と「学習のブラックボックス化」というジレンマ

――本日は、grasysが取り組むAI駆動開発についてインタビューを通じて迫りたいと考えています。さっそくですが、まずはご自身のキャリアの変遷と、grasysへ参画された時期について教えてもらえますか。

品地：これまでもフルスタックエンジニアとして複数の現場でキャリアを積んできましたが、grasysに入社したのは2024年の4月です。入社直後から、社内の基盤開発プロジェクトや、クライアント企業からお預かりしている大規模システムの運用・開発業務に携わっています。入社した当時は、世の中全体でAIを開発現場で使うことがあたりまえになろうとしていた、まさに開発の概念が大きく変わり始めようとしていた時期でした。

――技術の変化、具体的にはクラウドの進化やAIの浸透とともに、インフラと開発の境界線が曖昧になる中、grasysにおいてAIを本格的に開発プロセスへ組み込もうと決断した背景やその時期について教えてください。

品地：私が2024年に入社したころには、会社全体として一気にAIを開発プロセスへ導入しようという動きが進行していたように思います。私個人の実体験としても、2026年の1月や2月ごろからエンジニア界隈で「ハーネスエンジニアリングを実践することでほとんど手で書かなくていいぞ」という会話が出始めていました。自分としても、実際にAIエージェントを自身の開発環境に組み込んで試してみたところ、手動でのコーディングや手直しが劇的に減ったため、同年2月ごろからは本格的にAIをメインにした開発スタイルへと移行しました。

以前は、アーキテクチャの基本設計からロジックのコーディングに至るまで、すべて人間のエンジニアがゼロからタイピングして構築していましたが、現在ではその「コードを書く」という物理的な作業の大半をAIに取って代わられていると感じますね。

――grasysに入社し、AIを積極的に導入している現場にいるとのこと。実際に開発現場で実感している「圧倒的なメリット⁠」⁠、逆に直面した「技術的な壁や組織的課題」などがあれば教えてください。

品地：まず、明確なメリットとしては、IDE（統合開発環境）上での高度な自動入力が可能になったことや、チャットインターフェースを通じて自然言語で命令するだけで、複雑な環境操作やリファクタリングができるようになった点です。

たとえば、クラウドプロバイダから提供されるまったく新しい機能やAPIを利用する際も、公式ドキュメント（PDFやリファレンス）を丸ごとAIのコンテキストに読み込ませて「これ、どうやって私たちの環境に実装するの？」と聞けば、適切なコード実装まで一気に提案し、実装サンプルを出してくれるようになりました。これは認知的負荷の観点でも革命的と言えます。

一方で、デメリット（課題）として感じているのは、若手を含めた「エンジニアの根源的なスキル向上」が鈍るのではないかという懸念です。これまでは、公式ドキュメントと睨めっこしながらエラーを吐き出し、苦労してデバッグを行うことでシステムに対する深い「メンタルモデル」を構築していました。

しかし現在では、その過程が大幅に省略され、また必要以上に苦労しなくなり、「⁠とりあえずAIに任せれば、内部構造をブラックボックス化したままでも何か動くものができてしまう」という状態に陥りやすくなっています。結果として、本質的なアーキテクチャや技術の根幹を「泥臭く学ぶ機会」が減ってしまったように感じる部分は、今後の育成課題になるのではないか、と考えます。

LLMルーティング戦略⁠：タスクに応じたAIモデルの選定方針とトークン最適化

――開発においては、数あるLLM（大規模言語モデル）の中で、どのような基準でモデルを選定・ルーティングしているのでしょうか？

品地：「つねに最新の重いモデルを使う」のではなく、タスクの性質や複雑度によってAIモデルを明確に使い分けています。たとえば、単純なコーディングやリファクタリングのように、ある程度ルールや構文がテキスト化されており、作業内容が限定的で明確なタスクであれば、比較的古い世代の軽量モデルを使用します。これは、大量のコードを読み込ませてトークン消費量が多くなっても、コストが跳ね上がらないためです。

一方で、ゼロベースでの要件定義や、自分たちでもアーキテクチャの最適解が出ないようなスタック時、あるいはまったく別の視点から想定の範囲を超えるようなアイデアを出してほしいときには、最新かつ最も推論能力の高い賢いモデルを意図的に選ぶようにしています。

現在、OpenAIのChatGPTやGoogle CloudのGeminiなどを並行して活用していますが、とくにGeminiの最新モデルなどは、超長文脈のコンテキストを処理できる強みがあるため、各クライアントのインフラ構成や現行アーキテクチャに至った変遷の履歴に加え、類似する他顧客システムの社内ドキュメントをも包括的に参照・分析し、多角的なデータに基づいて今後の設計方針を策定することに利用しています。

もう1点、grasysはGoogle Cloudを基盤とした開発に強い会社でもあるので、その点でGeminiの相性の良さがあると思います。

ゼロトラストと権限管理⁠：セキュアなAI活用とレビューの属人化問題

――社会的にも開発の現場でAI導入が進む中、自社開発ではない、受託を含めたクライアント・パートナーの案件におけるAI活用ではセキュリティの担保が重要になります。
grasysでは、クライアントの重要なシステムを預かる上で、AIにコンテキスト（ドメイン知識）を渡す際のセキュリティや、アクセス権限（IAM）の管理について教えてください。

品地：大前提として、会社の方針として「誰がどのリソース・データにアクセスできるか」という権限は、IAM（Identity and Access Management）などによって厳格に集中管理されています。AIエージェントを動かす環境に関しても例外ではなく、この権限設計に完全に準拠させています。つまり、会社の機密情報や特定の顧客データなど、そのエンジニア個人が本来アクセス権を持たない情報については、AI側にも絶対に情報を渡せない（アクセスできない）アーキテクチャになっています。このガードレールがあるため、データ漏洩のリスクを極小化し、セキュアな環境下で安心してAIをフル活用できています。

――権限管理は万全な一方で、AIの出力品質のばらつきや、ハルシネーションに対してはどのように対応していますか？

品地：実はそこが、AI駆動開発における現在の大きなボトルネックです。AIが超高速でコードを出力してくるため、エンジニア自身がそのロジックを深く理解しないまま、「⁠とりあえずローカルで動いているから良し」としてPull Request（レビュー）に回してしまうケースが課題として顕在化しています。

一見すると実装フェーズが爆速で終わったように見えても、レビュアーの段階で確認すると、いくつかの問題が起こりうると考えています。

たとえば、「⁠リファクタ作業では小手先の対応をしたり、あるいは、リファクタで削除された関数が別の場所でそのまま放置されている」「⁠目的の理解不足の結果、1つの関数で複数の作業を行わせてしまう」「⁠対人用のコメントが不足している」といった点です。こうしたことが起こってしまう要因は、AIを利用している側が、そもそもAIに何をさせたいかを理解していないからです。

本来であれば、Human-in-the-loopの観点から、レビューを通す前の段階（エンジニア個人の責任範囲）でAIの出力を完全に理解し、コードオーナーシップを持った上で回さなければなりません。この「AIの生成スピードに人間の確認・理解スピードが追いつかない」という点が、実践上の大きな壁となっています。

AI駆動のテスト駆動開発（AI-TDD）⁠：自動化されたテストハーネスによる暴走ストッパー

――その「人間の確認漏れ」や「AIの品質ブレ」を防ぐために、grasysでは実際の開発現場ではAIをどのようなワークフロー（開発プロセス）に組み込んで制御しているのでしょうか？

品地：AIの暴走を防ぐ最大の仕組みとして、「⁠Issue Driven（課題駆動⁠）⁠」と「AIによるテスト駆動開発（TDD⁠）⁠」を組み合わせたフローを採用しています。

たとえば、GitHub上で「デモ用のECサイトに商品検索機能を実装する」といったIssueを、まずはAIが理解しやすい解像度の日本語で作成します。ここからがいきなり実装コードを書かせる従来の手法と違う点なのですが、私たちは実装の前に、AIに対して「developからfeatureブランチを作成し、tdd-playbookに従ってTDDで機能を実装してください。今回の対象Issueは#100です。まずはStep 1から始めてください」という指示を出します。

次に、テストケースの作成ができた時点で人間のテストケース内容の承認を待つ状態になるようにします。ここで、人間側で承認後、スキル内に記述してる実装ステップに移行してAIが実装を開始する流れとなります。

すると、AIはIssueの内容を読み解き、実装に必要なテストケースの枠組みを日本語で自律的に作成します。エンジニアは、生成される実装コードそのものではなく、まずこの日本語で定義されたテストケースの仕様とロジックを厳格にレビューします。

これにより、AIがこれから実装しようとしているスコープと人間が想定している要件に乖離がないか、テストケースを介して事前に正確な認識合わせを図ることができます。

もし私たちが想定していたビジネス要件とテストケースが完全に一致していれば、そのテストケースの枠組みを先にリポジトリへコミットします。

――なるほど。テストケースそのものを「AIに対する実行可能な要件定義（ハーネス⁠）⁠」として機能させるわけですね。その後の実装はどう進むのでしょうか？

品地：仕様を満たしたテストケースが確定した段階で、今度はAIに対して「テストケースを承認」と伝えます。AIは確定したテストケースという「絶対的な正解の枠組み」に基づいた後続の実装ステップを開始するので、エンジニアは他の作業をしながらAIの実装完了を待つだけになります。実作業としてはこのサイクルを高速で繰り返していく形になります。

実装フェーズに入る前に、テストケースの段階で人間が1回レビューを挟む（Human-in-the-loopを前倒しにする＝シフトレフトする）ことによって、AIの動きが要件から外れた間違った方向へ進まないよう強固なガードレールを敷いています。

最初から最後までAIに丸投げしてしまうと、方針やドメインロジックが間違ったまま大量のコードが生成されてしまい、後から人間が修正するコストが膨大になります。

しかし、この手法であれば、テストケースの段階で人間とAIの間で要件がしっかりと共有されているため、実装フェーズで仮にAIが一時的な誤りを出力しても、テストを通じてAI自身がその誤りに気づき、自律的に修正を重ねることができます。そのため、エンジニアがその都度細かく指示を出し直す必要はなく、テストがすべて通過して要件を満たす状態になるまでAIの自律的な実装完了に委ねることができます。

結果として、人間がレビューを行う時点ですでに要件を満たした実装が担保されるため、手戻りがなくなり、レビューの属人化も同時に解消できるのです。

grasys流の「知の共有」とエンジニア組織の進化

――AI時代において、エンジニア個人の知の習得（ナレッジマネジメント）や組織文化はどのように進化しましたか？

品地：技術の学び方や知識の吸収プロセス（Developer Experience）は、AIの導入によって根本から変わりました。以前は、新しいミドルウェアやアーキテクチャを学ぶ際、分厚い公式ドキュメントやPDFの技術書を上から下まで読み込んで学習していました。しかし現在では、そうしたフォーマットが固定された静的なPDFを人間が目で追って読むのは非常にしんどい（非効率的だ）と感じるようになっています。

代わりのアプローチとして、RAG（検索拡張生成）的な手法を用いて、対象のドキュメントを丸ごとAIのチャットエンジンにコンテキストとして読み込ませ、「⁠今回のプロジェクト要件において、注意すべき設定項目と必要な箇所だけを要約して出して」とプロンプトを投げるようになりました。これにより、AIが自社環境の文脈に合わせて「読むべきポイント」だけを動的に抽出して教えてくれる状態になり、技術検証のスピードが圧倒的に向上しました。

――そうしたAI活用のプロンプトエンジニアリングやワークフローの知見は、チーム内でどのように共有されているのでしょうか？

品地：属人的な「AIの使い手」に依存しないよう、チーム内では「Internal Developer Portal（社内開発者ポータル⁠）⁠」のような形で、誰かが作成して上手く機能した便利なAI操作スクリプトや、特定のコンテキストを注入するためのシステムプロンプトのテンプレートを共有する専用リポジトリを用意しています。そこにReadmeの形式でマークダウンのドキュメントを残し、他のメンバーも同じ環境・同じ精度でAIを即座に利用できる「再現性の高い仕組み」を整えています。

grasysが大切にしているのは、組織として必要なガードレールを定めたうえで、現場の裁量を大きくすることです。守るべきルールや重要な方針は経営層やマネージャから明確に示し、その範囲でエンジニア一人ひとりが自ら考え、判断し、工夫できる環境をつくっています。進め方を細部まで一律に決めるのではなく、現場から生まれるアイデアや可能性を最大限に活かすことを重視しています。

AI活用でも、任せること自体を目的にせず、業務の目的に応じて、AIに任せる部分と人が判断・確認する部分を見極めることが重要だと考えています。品質や安全性、確認・運用にかかる負担まで含めて、より良い成果につながる使い方を探っていく。そのために、現場の知識や経験を活かせる裁量が必要です。

我々が目指しているのは、技術力をもって顧客の課題を解決し、その目的を実現することです。AIは、そのために活用する手段の一つです。コードの実装やドキュメントの要点整理にAIを活用する場合も、エンジニア自身が内容や意図を理解し、判断することを大切にしています。クラウドインフラとアプリケーションの両面から、顧客にとって何が必要かを考え、設計・実装につなげていく。その過程でAIを効果的に活用することが、grasysの考えるAI駆動開発です。

grasysでは、顧客の課題や目的に向き合い、自ら考え、技術を選び、実現に取り組むエンジニアと一緒に働きたいと考えています。AIもそのための手段として活用していきたい。本記事を読んで「自分と合いそう」と思った方がいらっしゃれば、ぜひご連絡いただければと思います。

――ありがとうございました。