【前編】エージェンティックAIの「アウトプット品質安定化」を実現 GMOインターネットが実践する「ハーネスエンジニアリング」とは？ーEngineering Journey / 開発者向けブログ・イベント

ChatGPTの登場以降、開発現場では生成AIの活用が急速に広がり、GitHub CopilotやClaude Codeといったエージェント型ツールの導入も進んでいます。

こうした中、プロンプトエンジニアリング・コンテキストエンジニアリングに続く第三の潮流として、AIエージェントを取り巻く環境を整備することでアウトプットの品質を担保する「ハーネスエンジニアリング」に注目が集まっています。

GMOインターネットでは、自社で展開するConoHa・お名前.com・とくとくBBの各プロジェクトに加え、アプリケーション共通で使用する機能の認証基盤にてハーネスエンジニアリングを試験的に導入し、検証を進めています。

今回は、GMOインターネット内でハーネスエンジニアリングの検証・導入を進めるAIアンバサダー8名に話を伺いました。前編では、ハーネスエンジニアリングの概要や検証の中で見えてきた成果、仕事の変化などを紹介します。

AIの「手綱」を握り、アウトプットの質に再現性を持たせる

◇リーダー
谷中佑貴人(やなかゆきと)
所属：GMOインターネット株式会社システム本部アーキテクチャー統括アプリケーション共通チーム (グループ広報部技術広報チーム兼務)
役職：マネージャー

◇メンバー
井上弘規(いのうえひろき)
所属：GMOインターネット株式会社システム本部ドメイン・クラウド開発部お名前フロントエンドチーム

瀧谷悠(たきたにゆう)
所属：GMOインターネット株式会社システム本部ドメイン・クラウド開発部 ConoHaバックエンドチーム
役職：リーダー

井上優也(いのうえゆうや)
所属：GMOインターネット株式会社システム本部ネットワークソリューション開発部 NSフロントエンドチーム

藤嶋智晃 (ふじしまともあき)
所属：GMOインターネット株式会社システム本部アーキテクチャー統括アプリケーション共通チーム
役職：リーダー

舟木博和(ふなきひろかず)
所属：GMOインターネット株式会社システム本部アーキテクチャー統括アプリケーション共通チーム
役職：リーダー

平野空暉（ひらのそらき）
所属：GMOインターネット株式会社システム本部 ConoHa開発部 ConoHaバックエンドチーム（ドメイン・クラウド事業本部プロダクトマネジメントチーム兼務）

大山仁(おおやまひとし)
所属：GMOインターネット株式会社システム本部ビジネスサポートプロダクトチーム

——まず前提として、「ハーネスエンジニアリング」とはどのような概念なのでしょうか。

谷中

一言で言うと、「仕組みでAIの出力品質を安定化させる」考え方です。ハーネスというのは馬につける手綱（馬具）のことですが、さまざまなルールや制約・自動検証などを組み合わせた構造を使って、AIエージェントを制御していこうという発想ですね。将来的には、AIによる自律的なシステム開発を実現したいと考えています。

AIを使った開発の歴史を振り返ると、最初は良いプロンプトを書くことに注力するプロンプトエンジニアリングに始まり、次にAIに渡す文脈を設計するコンテキストエンジニアリングへと発展してきました。ハーネスエンジニアリングは、その次のステップにあたる概念だといえますね。

従来の手法では、AIのアウトプットの質が「人間がどれだけうまく指示を書けたか」という個人のスキルに担保されていたため、品質の向上には一定の限界がありました。プロンプトは毎回書き直すため品質の再現性が担保されませんが、ハーネスは一度整備すれば同じ品質を何度でも再現・供給できます。

一度整備すればその後の開発生産性が向上するという、「複利で効いていく仕組み」である点こそが、ハーネスエンジニアリングの本質です。これまではソースコードを我々の価値や資産として位置づけてきましたが、これからのエンジニアの価値や仕事の中身は「AIが動きやすい環境を整備する」ことへとシフトしていくでしょう。

谷中佑貴人（やなかゆきと）｜GMOインターネット株式会社システム本部アーキテクチャー統括アプリケーション共通チーム (グループ広報部技術広報チーム兼務)｜マネージャー

——ハーネスエンジニアリングの取り組みを始めたきっかけは何だったのでしょうか。

谷中

振り返ると、2023年の11月ごろにGitHub Copilotが使える環境を整備するところからAIエージェントへの取り組みを開始したことがそもそもの始まりでしたね。

その後はさらにDevinからClaude Codeへとシフトしていったのですが、部分的な効率化を進めていく過程で「いくら試行錯誤しても、開発生産性はだいたい2倍あたりで頭打ちになる」という現実が見えてきたんです。

これを5倍・10倍と伸ばしていくためには、AIエージェントに適した開発プロセスや開発の仕方そのものを変えなければならないと分かり、さまざまな手法を探っていくなかで解決策の1つとして出てきたのが、OpenAIの公式記事で言及されていたハーネスエンジニアリングでした。

その時点ではまだ「ハーネスエンジニアリング」という言葉自体は使われていませんでしたが、意図を伝えればエージェントが自走して行動を完結するという、ハーネスエンジニアリングそのものの事例が紹介されていたんです。そこから着想を得て情報を追っていくうちにこの言葉に行き当たり、実際に着手したという流れです。

「正解のない問題に答える」苦労を乗り越えて生まれた成果

——AIエージェントは少しずつ取り組む企業が増えてきましたが、まだメインストリームにはなっていないように思います。エージェントの導入に際して、苦労した点はありましたか。

谷中

AIの進化は著しいので、使用するツールも頻繁に変わるだろうという想定は最初からありました。ただ私は部門横断で予算管理やコスト調整も担当しているので、Copilotを導入するにあたってもどういうプランで現場に展開するかは悩みましたね。

Claudeでも同じで、本気で使おうとするとClaude Maxプランは個人契約しか選べません。法人として使うならエンタープライズ版のような包括契約を結びたいのですが、AI時代においてエンタープライズ契約に縛られてしまうと、次のトレンドが来たときに乗り換えられない。そうした事情を考慮しながら予算を確保することも苦労した点ですね。

平野

現場目線で言うと、どこまでやっていいのかが分からないまま進めないといけないというのが厳しかったです。これまでの社内規則は「これをしてはいけない」という形で書かれているものが多かったのですが、AIは人間の想像力次第で何でもできてしまうので…。

過去には「ClineにGitHub Copilotのキーを利用してよいのか？」といった論点がありましたが、こうした「正解を誰も知らないから誰にも聞けない」という状況が今なお続いています。AI技術の進歩は著しいだけに、こうした流れは今後も止まらないでしょうね。

瀧谷

私の感覚では、苦労した点は大きく2つあります。1つは既存ソースへの適用、もう1つはツールやAIエージェントの最適な使い方に関する情報のキャッチアップです。

前者については、実運用されているコードありきで導入することになるため、「このディレクトリの配下だけは別のルール」といったローカル事情のような、「コードベースに明文化されていない不文律」をうまく扱えるようにハーネスを設計していくところに心を砕きました。

後者については、Devinから始まって今はClaude Codeがメインストリームとなっていますが、その間にもAntigravityの登場などツールの移り変わりが非常に激しかったですよね。自分たちにとって最適なものは何かを、普段の業務をこなしながら追いかけ続けるのも大変だったなと。

谷中

我々のチームメンバーが参画しているSlackのチャンネルでは、技術記事をお互い投下しあうという文化があるので、現在はそこでいろいろな記事を投げ合って最新の情報をキャッチアップしているという感じですね。

——現在は先行プロジェクトでハーネスエンジニアリングを検証中とのことですが、それぞれの検証の中で見えてきた成果と課題を教えてください。

舟木

当社にはテスト自動化の文化自体はあるのですが、会社の歴史が長いため、自動テストが浸透する前から続いているサービスも存在します。正直なところ、サービスによって自動テストの充実度やカバレッジにはばらつきがありますね。

とくに昔からあるサービスでは、そもそもテストコードを書きやすい構造になっていないものもあります。こうしたケースではリファクタリングなど、ハーネスを導入するための準備から始めなければなりません。こうした前提条件の違いを埋めていくところが今後の課題です。

平野

一方で、特定のタスクにおいては明確な成果が出ています。たとえばデザインにおける「正しい」データがあって、それに向けてコーディングをするようなケースですね。こうしたケースではスクリーンショットを両方撮って比較すれば完全な正誤判定ができるので、ルールを定めた後はAIに自律的に動いてもらう、という状態が少しずつ作れてきました。

明確な正解が厳密に定義されているAPI開発なども同様です。まだまだ試行錯誤のフェーズではありますが、こうした領域を広げていけばさらなる成果につながっていくでしょう。

谷中

横断的な数値としての成果も上がってきました。これはハーネスエンジニアリング単体の成果ではなく、2023年から続けてきた社内のAI活用全体としての話になりますが、2026年1Q時点で、50%の開発工数削減を達成しています。PLベースで人件費換算すると、約5,300万円のコスト削減につながった計算ですね。

開発にかけていた時間が単純に半分になったにもかかわらず、アウトプットの量は変わっていないという状況ですが、この50%削減をさらに引き上げていくための新しい打ち手がハーネスエンジニアリングという位置づけです。

足元の目標は開発生産性5倍に置いていますが、将来的には10倍を目指していきたいと考えています。

AI時代のエンジニアの価値は「本質的な価値創出」にあり

——ハーネスエンジニアリングの導入前後で、働き方や仕事に対する意識は変わりましたか。

平野

エンジニア視点では、視座が高まった感覚があります。これまではレビューをする際に、変数の綴りや改行位置など「本質的ではない部分」にも意識を割かなければいけませんでした。それがハーネスに吸収されるようになったことで、全体の設計や抽象度の高い領域を俯瞰的に見る機会が増えてきましたね。

本来はアーキテクトや役職の高い人が見るような領域を、シニアエンジニアでも見ざるを得ない、あるいは見られるようになってきたというのは大きな変化だと感じています。

瀧谷

最近は明らかに難しいことをやっているな、という感覚があります。以前は「こういう感じに動くものを作って」とタスクを与えられて、その通りに動くものを作るだけだったのですが、今はプロンプト1つで割と動くものが出来上がってくるので、その先の部分に取り組む場面が増えてきましたね。

「アーキテクチャをどう良くしていくか」のような決まった正解がないことの多い問題や、「この動作は何ミリ秒以内に収めよう」といった、実装しているだけでは見えてこなかったパフォーマンス面に目を向けることが多くなったと感じます。

もう一つ明確に変わったのが、後輩からプログラムについて質問される機会が目に見えて減ったことです。プロンプト1つで動くものが生成できるようになったことで、ジュニアクラスのエンジニアでも、実装やコードリーディングといった領域は1人で進められるようになってきました。

だからこそ、後輩から質問をもらった際に改めてコードを読み直したり、資料を眺めて思考を整理したりするという「自分自身の学びの機会」が減っていると実感しています。正直なところ、中堅エンジニアとしては少し寂しさもありますね。

平野

学びの機会が自然には生まれにくくなっているからこそ、このチームで週3回ほどのペースで議論したり、Slackで新しい発見を積極的に投稿し合う場を持つといった取り組みには意味があると感じています。これもAI時代ならではのやり方ですね。

——AIが個人の能力を拡大させるからこそ、熟練度に関わらずより本質的な部分にコミットできるか、価値を創出できるかが問われるのですね。

舟木

セキュリティの観点でも同じことが言えます。これまでは自分で知識を身に着け、その知識を基に開発するという流れでした。しかし、今はそれをセキュリティテストツール等で自動検知の仕組みに落とし込むところまで考えなければ、AIに守らせることができません。

藤嶋

これまで口伝えなどで緩く共有されていた認識やノウハウを、AIが判断に困らないような形で明文化して、リポジトリに情報として残していかなければいけなくなったという点も大きな変化です。

そうしてリポジトリ側に情報を揃えておけば、全然知らないリポジトリを触るときでも、AIに聞けばちゃんとした答えが返ってくる状態にできるんです。これは大きなメリットですね。

井上弘

開発の「終わり方」も変わりました。以前は開発が終わればそれで終了でしたが、ハーネスを導入してからは、開発が終わった後にそのやり取りを振り返って「どうハーネスを改善できるか」を考えるところまでが重要になってきています。

谷中

マネージャーの立場で現場を見ていると、エンジニアの評価尺度が変わってきていることを実感しますね。これまでは、各エンジニアの力量をそれぞれの書くコードの量や質といった部分で評価していましたが、今は「どれだけAIをうまく活用できているか」が評価に直結しています。

エンジニアに求められるものも変化する昨今ですが、エンジニアがハーネスの設計に注力することで、AIを活用した開発の質はさらに磨かれていくと信じています。