AI/機械学習 の記事一覧

はじめに こんにちは。GMOインターネットの平野です。 以前、ハーネスエンジニアリングの紹介記事では、ConoHa VPS MCPサーバー開発で実践したハーネスエンジニアリングの具体的な仕組みを紹介しました。「何をやったか」の話です。今回は一段メタな視点で、「なぜそうなるのか」を掘り下げます。ハーネスエンジニアリングとは、結局のところ何をしているのか。その本質と思想を整理します。 本質: 従来の開発規律の再設計 ハーネスエンジニアリングの本質は、新しい規律の発明ではありません。 テスト、CI、リンター、コードレビュー、ADR （Architecture Decision Records）──これらは従来からやるべきだった開発規律です。ハーネスエンジニアリングの新しさは、これらをエージェントが end-to-end で回せるように再設計している点にあります。 4 つの再設計軸 従来の開発とハーネスエンジニアリングの違いを、4 つの軸で整理します。 再設計軸従来ハーネスエンジニアリング実行環境人間がローカルで実行エージェントが Hooks・CI で自律的に駆動知識配置Wiki等に記述的に蓄積メタデータ付きのMarkdownファイル検証ループCI → 人間レビュー → 修正PostToolUse（ms）→ プリコミット（s）→ CI（min）で自己修正運用経済人間の時間が律速、慎重にマージエージェントの実行時間が律速、「修正は安価、待機は高コスト」 この 4 軸は、ハーネスエンジニアリングを考えるときの基本的なフレームワークになります。 制御なき AI コーディングの課題 ハーネスなしで AI に自由にコーディングさせると、以下の問題が構造的に発生します。 一貫性の欠如: ファイルごとに実装パターンがずれる、命名規約に揺れが出るアーキテクチャの崩壊: 境界を越えた import が紛れ込む、レイヤー設計が壊れる技術的負債のサイロ化: エントロピーが増大し、各セッションが独立した負債を生産する これらは AI の能力不足ではなく、制約の不在が引き起こす構造的問題です。人間の開発者でも、レビューやルールがなければ同様のことが起きます。AI の場合、速度が速いぶん、問題の蓄積も速くなるだけです。 プロンプトの限界とハーネスの複利効果 「AI に良いコードを書かせたいなら、良いプロンプトを書けばいい」──これは直感的には正しく聞こえます。しかし、この方法には構造的な限界があります。 プロンプト依存の限界: AI に高品質を求めるほど、指示が肥大化する指示が肥大化するほど、品質担保が「人間がプロンプトを正しく書けたか」に依存するプロンプトは毎回書き直す消耗品であり、セッションをまたいで蓄積しない 一方、ハーネスは一度作れば繰り返し品質を安定供給できます。たとえば、リンタールールを 1 つ追加すれば、以降すべてのセッションでそのミスが防がれます。 プロンプトは単利、ハーネスは複利です。 もちろん、プロンプトが不要になるわけではありません。プロンプトは「何をつくるか」の方向づけに不可欠です。ただし、「どう品質を守るか」をプロンプトに頼り続けるのは、スケールしない方法だということです。 6 つの核心原則 ハーネスエンジニアリングの設計を支える原則を 6 つに整理します。 品質の源泉は「仕組み」: プロンプトではなく、ハーネスで品質の不確実性を除去する速度こそが品質: フィードバックループの速さが品質を規定する。ms 単位でエラーを発見できれば、修正コストは限りなく小さくなる制約がエージェントを導く: 自由度ではなく「制約」で一貫性と予測可能性を両立させるルールは陳腐化が前提: ルールの鮮度の自動検証、AI レビューを実施する機械的に検証しづらい品質も測る: 機械的に検証しづらい品質基準も言語化し、AI に提供することで、機械的検証の死角をカバーする自律に耐えうる設計: ルール自体の運用（追加・変更・廃止）を、エージェントが実行できるように明示する 原則 6 は特に重要です。ルールを作るだけでなく、ルールのメタ運用自体もエージェントが参加できるよう設計する。これによって、ルール体系そのものが自律的に進化し続けるための土台ができます。 広義と狭義のハーネスエンジニアリング 広義: 3 つの柱の統合 ハーネスエンジニアリングを広義に捉えると、3 つの柱で構成されます。 コンテキストエンジニアリング ──エージェントに「何を守るべきか」を正しく伝える CLAUDE.md の設計（50行以下、詳細はオンデマンドロード）計画と実行の分離（エージェントに計画を立てさせ、人間がレビューしてから実行）Skillsやコーディングパターンのドキュメントのメタデータ設計 ハーネス（制約） ──不変条件を機械的に検証し、違反をブロックする リンター、テスト etc...Hooks による開発時ガード構造テストによるアーキテクチャ不変条件の固定 ガベージコレクション ──ルール体系そのものの劣化を検知し、鮮度を保つ ルールの鮮度チェックADR によるルール変更経緯の記録 この 3 つの柱は独立しているのではなく、互いに依存しています。コンテキストエンジニアリングがなければ制約は伝わらず、制約がなければ品質は守れず、ガベージコレクションがなければ制約は陳腐化します。 狭義: 制約で狭める 狭義のハーネスエンジニアリングは、2 番目の柱──制約による品質担保──に焦点を当てます。 エージェントの解決空間を広げるのではなく、狭めることで一貫性と予測可能性を高める「自由にやらせて後でレビュー」ではなく、「最初から選択肢を絞り、逸脱を即座に検知」制約がエージェントを弱くするのではなく、制約がエージェントを強くする ここでのポイントは、今すぐ機械で判定できないルールであっても、言語化しておく価値があるということです。定義さえあれば、将来のツール改善によって自動化が可能になります。定義がなければ、永遠に暗黙知のまま残ります。 運用思想: 人間とエージェントの役割分担 人間の役割──方向づけと判断 優先順位付け: 何を先にやるか、何を後回しにするか受け入れ基準の定義: 完了条件を曖昧にせず言語化する成果検証: エージェントの出力が意図と合致しているか確認例外判断: ルールから外れるべきケースの判断（ADR として記録） 人間は主にプロンプトで方向づけし、エージェントが実装・レビュー対応・修正まで進めます。 エージェントの役割──実行と自己修正 エージェントは、人間が設計した制約の中で、end-to-end の実行ループを自律的に回します。 実装レビュー指摘への対応テスト修正 重要なのは、エージェントに「何でもできる自由」を与えることではなく、「制約の中で確実に動ける仕組み」を提供することです。 暗黙知の排除原則 すべてのルールはまず知識として全情報をAIに渡します。人間だけが感覚で知っている状態を排除する──これが運用思想の根幹です。 人間が暗黙的に持っている品質基準を、明示的に言語化してAIに渡す「わかっているはず」「常識だろう」という前提を排除し、すべてを機械可読な形で記述する 暗黙知の排除は、AI のためだけの施策ではありません。新しいチームメンバーのオンボーディングにも、同じ形で効きます。 運用経済: 「修正は安価、待機は高コスト」 従来の開発では、人間の時間が最も高コストでした。だからこそ「慎重にレビューし、確実にマージする」ことが合理的でした。 エージェント駆動開発では、この経済構造が反転します。 観点従来の開発エージェント駆動開発最も高コストなもの人間の時間エージェントの待機時間マージ戦略慎重にレビューを行うお客様影響がないと言い切れるものはレビューを最小限にし、スループットを上げる この経済観から導かれる設計判断 人間の承認待ちがボトルネックにならないよう、自動マージ可能な範囲を広げるフィードバックループの高速化を行うために、PostToolUse（ms）で直せるものを CI（min）まで待たせない フィードバック速度のパラダイムシフト 従来は人間によるレビュー（数時間）が品質の最終防衛線でした。ハーネスエンジニアリングでは、この防衛線をツール実行（数ミリ秒）へシフトさせます。 レイヤー速度性質PostToolUsems機械的・即時Pre-commitsローカル環境CIminリモート環境Human Reviewh人間的・遅延 CI で落ちてから気づくのではなく、開発ループの中で「その場で正される」即効性が品質を生みます。できるだけ多くのチェックを、最も速いレイヤー（ms）に移動させることがハーネス設計の基本原則です。 まとめ ハーネスエンジニアリングの本質は、「新しい規律の発明」ではなく「既存の開発規律を、エージェントが回せるように再設計すること」です。この記事の要点を 2 つに整理します。 1. 制約がエージェントを強くする エージェントの能力を引き出すのは自由度ではなく制約です。制約を強め、逸脱を即座に検知する仕組みが、一貫性と予測可能性を生みます。プロンプトによる毎回の指示（単利）ではなく、ハーネスという仕組みへの投資（複利）が、長期的に品質を安定させます。 2. 暗黙知を排除し、すべてを機械可読にする 人間だけが感覚で知っている状態を排除し、ルールを明示的に言語化する。今すぐ自動化できなくても、デジタルで定義しておくことで、将来の自動化への道が開けます。ルールの追加・変更・廃止というメタ運用も含めて、機械可読に設計することが、自律的に進化するルール体系の土台になります。 以前紹介した記事の実践は、この思想の具体的な表現です。個々のテクニックとして消費するのではなく、「従来の開発規律の再設計」というフレームで捉えることで、自分たちのプロジェクトに合った仕組みを設計するヒントになれば幸いです。 また、ハーネスエンジニアリングについての弊社の取り組みについて、インタビュー記事も公開されました。よかったら合わせてご覧いただけますと幸いです。

GMOインターネットグループエキスパート黒瀧です。今回は、SUZURIの公開APIを活用してMCP（Model Context Protocol）サーバーを作った話を紹介します。 はじめに MCPは、AIアシスタントが外部のツールやデータソースと連携するための標準プロトコルです。Claude DesktopやClaude CodeなどのMCPクライアントに対応したアプリケーションから、さまざまな外部サービスを自然言語で操作できるようになります。SUZURIにはAPIが公開されているので、これをMCPサーバーとしてラップすれば、AIアシスタントとの対話を通じてSUZURIの操作ができるのでは？と思い、開発してみました。npm パッケージとして公開しています。 @kurotaky/suzuri-mcp-server - npm 注意: このMCPサーバーはSUZURIの公式プロダクトではありません。個人が開発・公開しているものです。 SUZURI APIについて SUZURIでは開発者向けにAPIが公開されており、[SUZURI Developer]（https://suzuri.jp/developer) ペジからアプリケーションの登録やAPIトークンの発行ができます。このAPIを使うと、商品の検索・取得、素材のアップロード・管理、ユーザー情報の取得、ズッキュン（お気に入り）の操作など、SUZURIの主要な機能をプログラムから利用できます。今回作ったMCPサーバーは、このSUZURI APIをMCPのツールとしてラップしたものです。 セットアップ方法 事前にSUZURI Developerページでトークンを発行しておきます。Claude Codeをお使いの場合、以下のワンライナーでセットアップできます claude mcp add suzuri -e SUZURI_TOKEN=your-token-here -- npx -y @kurotaky/suzuri-mcp-server Claude Desktopの場合は、設定ファイル（claude_desktop_config.json）に以下を追加します。 { "mcpServers": { "suzuri": { "command": "npx", "args": ["-y", "@kurotaky/suzuri-mcp-server"], "env": { "SUZURI_TOKEN": "your-token-here" } } } } 設定後にアプリを再起動すれば利用可能です。 できること 27個のツールを用意しており、SUZURIの主要な操作をカバーしています。 カテゴリ主なツールできることProductssearch_products, get_productキーワードで商品を検索、商品詳細の取得Materialscreate_material, create_text_material画像URLやテキストから素材を作成・管理Itemslist_itemsTシャツ、マグカップなどアイテム種別の一覧取得Usersget_current_user, update_userユーザー情報の取得・プロフィール更新Favoritesadd_favorite, remove_favoriteズッキュンの追加・解除Activitieslist_activitiesアクティビティの確認Placementpreview_product_placement, compare_placements配置のプレビュー・比較Choicescreate_choice, update_choiceチョイスの作成・管理 動作イメージ Claude Codeからプロフィール画像をアップロードし、Tシャツを作成した例 おもしろ機能: Claude Codeでお手入れ（プレビュー） 個人的におもしろ機能として、Claude Code上で画像の配置をプレビューしながら調整できる「お手入れ」機能を作ってみました。 配置プレビュー preview_product_placement ツールを使うと、素材の配置（拡大率・位置）を指定してプレビュー画像を確認できます。Claude Codeの対話の中で「もう少し左に寄せて」「サイズを小さくして」といった自然言語での指示が可能です。 配置の一括比較 compare_placements ツールでは、複数の配置パターンをブラウザで一覧比較できます。実行するとローカルにHTTPサーバーが立ち上がり、カード形式のUIで各パターンを並べて表示します。気に入った配置を選択すると、その結果がClaudeCodeに返されます。 4パターンの配置をブラウザで一覧比較できる 配置プリセット よく使う配置パターンを「プリセット」として9種類用意しています。 プリセット説明center標準サイズで中央に配置left_chest左胸にワンポイントright_chest右胸にワンポイントfull_front大きく全面プリントbottom_center下部中央に配置top_center上部中央に配置pocket_area胸ポケット位置に小さく配置mug_wrapマグカップ表面を覆う配置small_center中央にコンパクトに配置 インタラクティブな配置フロー これらのツールを組み合わせると、以下のような対話的なフローが実現できます。 プリセットから候補を選ぶcompare_placements でブラウザ上で比較気に入ったパターンをベースに「もう少し大きく」などと微調整create_product_with_placement で確定した配置で商品を作成 AIとの対話で自然にグッズのお手入れ（配置調整）ができるのは、なかなか楽しい体験です。 まとめ SUZURIの公開APIをMCPサーバーとしてラップすることで、AIアシスタントから自然言語でSUZURIを操作できるようになりました。特にお手入れ（配置プレビュー）機能は、対話しながら視覚的に確認・調整できるので、MCPならではの体験だと感じています。SUZURIのAPIが充実していたおかげで、比較的スムーズにMCPサーバーを構築できました。MCPに興味がある方は、お気に入りのサービスのAPIをMCPサーバー化してみると、AIとの新しい連携の可能性が広がるかもしれません。リポジトリはこちらです。https://github.com/kurotaky/suzuri-mcp-server

はじめに こんにちは。GMOインターネットの平野です。 前回の記事では、AIコーディングエージェントの出力品質を「構造」で担保するハーネスエンジニアリングの考え方と、4段階エスカレーションラダー（L1〜L4）の実装について紹介しました。 このハーネスをしばらく運用してきて、自然と浮かんできた問いがあります。 「ここまで構造で品質を守れるなら、人間のコードレビューはどこまで必要なのか？」という問いです。 先に結論を言うと、コードレビューを全廃できるとは考えていません。ただし、レビューが拾っているものを分類してみると、その大部分はハーネスとAIで代替できる作業であり、人間が本当に見るべき領域はもっと狭い、ということがわかってきました。この記事では、その分類と、移行をどう判断するかについて整理します。 レビューがボトルネックになる構造 AIにコードを書かせると、コーディングの速度は確実に上がります。一方で、レビューの速度は人間の処理能力に縛られたままです。 開発スタイルコーディング速度レビュー速度ボトルネック人間が書き、人間がレビュー1x1xなし（均衡）AIが書き、人間がレビュー5~10x1xレビューが律速AIが書き、ハーネス+AIがレビュー5~10x自動化解消 この構造を放置すると、「レビューを省略して速度を取るか、レビューを維持して品質を取るか」という二択に追い込まれます。どちらも望ましくありません。必要なのは、レビューの中身を分解して、自動化できるものとできないものを仕分けることです。 コードレビューが拾うものを分類する コードレビューで指摘される内容を整理すると、大きく4つのカテゴリに分かれます。 カテゴリ内容自動化Aハーネス違反の検出可能B-1ハーネス自体の矛盾不可B-2ハーネス不足不可C要件・設計の妥当性スコープ外 カテゴリA: ハーネス違反の検出 命名規約やアーキテクチャ境界、実装パターンへの準拠など、既存のルールに対する違反を見つける作業です。「camelCaseになっていない」「レイヤーを越えたimportがある」「パターンファイルで定義した実装方針と違う」といった指摘がここに入ります。 カテゴリB-1: ハーネス自体の矛盾 ルール体系そのものに矛盾がある場合です。たとえば、あるルールは「すべてのスキーマに.strict()をつける」と言い、別のルールは「外部APIレスポンスには.passthrough()を許容する」と言っている。外部APIのレスポンスをバリデーションするスキーマはどちらに従うべきでしょうか。こうした矛盾は、ルールを個別に見るだけでは気づけません。特に、新しいルールを追加するとき、ルール体系をリファクタリングするときに発生しやすくなります。パターンファイルが推奨するディレクトリ構造と、別のパターンファイルが前提とするインポートパスが噛み合わなくなる、といった事態は、ルールが増えるほど起きやすくなります。 カテゴリB-2: ハーネス不足 ハーネスがまだカバーしていない領域の発見です。たとえば、新しいライブラリやフレームワークが追加されたのに、それに対するルールが整備されていないとき、また、既存ルールの粒度では捕捉できないクラスのバグが起きたとき、「ルールを足すべきだった」と事後的に気づくケースもあります。AIは「既存ルールに違反していない」ことは判定できますが、「ルールが足りない」ことは判定できません。「ルールが無いから通過」と「ルールが不要だから通過」の区別がつかないのです。 カテゴリC: 要件・設計の妥当性 そもそもこの実装が問題を正しく解決しているか、アーキテクチャ上の判断は妥当か、という問いです。これはコードレビューというより設計レビューであり、判断基準もタイミングも異なります。設計レビューは本来、実装に入る前に行うべきものです。コードレビューの場で「そもそもこの方針で合ってるのか」が議論になるのは、設計レビューとコードレビューが混同されている兆候であり、プロセス自体を見直すべきサインです。本稿ではカテゴリCをスコープ外とし、コードレビューの中で扱うべきA・B-1・B-2に焦点を当てます。 機械に任せられるもの、人間が見るべきもの カテゴリA: ハーネス違反の検出 ハーネス違反は、決定論的なものと確率的なものに分類できます。リンター等による決定論的な検出は、見落としがなく、人間も疲れません。確率的な検出は現時点では人間と同等かやや劣る可能性がありますが、ここは後述する並行運用で検証できます。 カテゴリB-1: ハーネス自体の矛盾 一方、ハーネス自体の矛盾の検知を自動化できない理由は構造的なものです。ハーネス矛盾（B-1）について言えば、AIはルールを公理として受け取ります。公理は「従うもの」であり「疑うもの」ではありません。公理系の内部矛盾を検出するには、その系の外に立ち、ルール同士の関係を俯瞰する視点が必要です。これは本質的にメタレベルの作業であり、現状のAIにはこの自発的な「一歩引いた視点」が欠けています。 矛盾が特に発生しやすいのは、次のようなタイミングです。 新ルールの追加時（既存ルールとの整合性チェックが漏れる）ルールの昇格時（執行レベルの変更による副作用が見えにくい）ルール体系のリファクタリング時（分割・統合で前提が崩れる） だからこそ、ハーネス自体を変更するPRには、必ず人間のレビューを通す必要があります。ハーネス変更のレビューは省略してはいけません。 カテゴリB-2: ハーネス不足 ハーネス不足（B-2）について言えば、AIは「ルールがないから通過」と「ルールが不要だから通過」の区別がつきません。ルールが存在しない領域では、AIは何もフラグを立てずに通過させます。 これはAIの欠陥ではなく、ルールベースなシステムの構造的な限界です。経験あるエンジニアがレビューで拾うのは、まさにこの「ルールがまだない領域」の問題であることが多い。「このパターン、うちのコードベースに入ったの初めてだけど、ルール化しなくて大丈夫？」「この新しいライブラリの使い方、パターンファイルに追加しておいたほうがよくないか？」といった問いかけは、ハーネスの外にいる人間にしかできません。こうした指摘は、ハーネスを育てる上で最も価値のあるフィードバックになります。 カテゴリC: 要件・設計の妥当性 カテゴリC（設計の妥当性）については、ハーネスの守備範囲外です。「このAPIの設計は利用者にとって使いやすいか」「この機能の責務配置は将来の拡張に耐えられるか」といった問いは、コードの正しさではなく設計の判断に関わるものです。こうした問いは実装に入る前の設計段階で扱うべきであり、コードレビューの場に持ち込むと、レビューの焦点がぼやけます。設計レビューとコードレビューを明確に分けることで、それぞれのプロセスが本来の役割に集中できるようになります。 カテゴリBとCを整理すると、人間がレビューで注力すべき領域がはっきりします。この構造は、自動テストの普及がQAの役割を変えた流れに似ています。手動テストが自動テストに置き換わったとき、QAは「テストを実行する人」から「テスト戦略を設計する人」になりました。同様に、コードレビュアーは「違反を検出する人」から「違反を検出する仕組みを設計する人」へと役割が変わっていくと考えています。 統計で判断する: 並行運用モデル カテゴリAが自動化可能だとしても、「いつ人間レビューをやめるか」を感覚で決めるべきではありません。並行運用でデータを取り、統計的に判断するアプローチを考えています。 フェーズ1では、人間レビュアーとAIハーネスの両方がすべてのPRをレビューします。人間レビュアーはAIの結果を見ずに独立してレビューし、両者の指摘を記録して差分を分類します。そして、以下のメトリクスを計測します。 メトリクス定義目標AIの見落とし数人間が検出したがAIが見逃した違反低下傾向人間の見落とし数AIが検出したが人間が見逃した違反ベースライン偽陽性率AIが指摘したが人間が却下したもの / AIの全指摘数閾値以下 ここで重要なのは、人間見落とし数を計測する点です。人間もまた見落とすことは多々あります。AIの見落とし数が人間の見落とし数を下回れば、AIに委譲する統計的な根拠が成立します。 フェーズ2においてAIの見落とし数が人間の見落とし数をN週連続で下回った時点で、カテゴリAの人間レビューを任意化します。ただし、まず低リスクなPR（小規模変更、既知パターンのみ）から人間レビューを省略し、段階的にスコープを広げます。異常があればフェーズ1に戻ります。セキュリティやデータ損失に関わる重大な違反については、統計的にAIが優勢でもサンプリングベースで人間レビューを継続することを想定しています。稀だが重大な問題は、統計の平均値だけでは捉えきれないからです。 条件閾値判定AI見落とし数 < 人間見落とし数N週連続で達成カテゴリAの人間レビューを任意化偽陽性率X%以下を維持レビュアーの信頼が維持される重大違反の見落とし0件移行の前提条件 まとめ コードレビュー不要論の核心は、「レビューをやめる」ことではなく、レビューの対象を再定義することです。今回の議論は、次の3つに整理できます。 1. レビューの分類が自動化の出発点 コードレビューが拾うものは一枚岩ではありません。ハーネス違反の検出、ハーネス自体の矛盾、ハーネスの不足、設計の妥当性。分類して初めて、何が自動化でき、何に人間の判断が必要かが見えてきます。 2. ハーネスの「中」は機械、「外」は人間 既知のルールに対する適合チェックは、レビューの最大ボリュームでありながら、構造的に自動化可能な作業です。一方、ルール体系自体の矛盾や不足は、ルールの外に立つ視点でしか見つけられません。人間のレビューは、この「外」を見ることに集中すべきです。 3. 移行はデータで判断する 「AIのほうが賢そうだから」は、移行の根拠になりません。並行運用で人間とAIの見落とし率を比較し、統計的にAIが人間と同等以上であることを確認してから移行する。このプロセスを踏むことで、感覚ではなくエビデンスに基づいた判断ができます。 コードレビューが不要になるのではなく、コードレビューの対象が「コード」から「ハーネス」に移行する。レビュアーの役割は消えるのではなく、より高いレイヤーへ移る。これが、ハーネスエンジニアリングを運用してきた先に見えてきた景色です。 また、ハーネスエンジニアリングについての弊社の取り組みについて、インタビュー記事も公開されました。よかったら合わせてご覧いただけますと幸いです。

2026年3月5日に開催された「第3回GMO大会議・春 サイバーセキュリティ2026」の第2部では、特別対談やGMO Cybersecurity Awards 2026表彰式、将来戦や犯罪対策に迫るパネルディスカッションなど多彩なプログラムが展開されました。サイバー攻撃の最新手口やさまざまな提言・意見が語られた第2部の模様をお伝えします！ イベントレポート前編はこちらから 特別対談「『生成AI時代』のサイバーセキュリティと経営の防衛戦」 AI技術を使った最新の攻撃手段や企業経営といった、幅広いテーマが語られた大会議の前半。さらに白熱したセッションが展開された後半は、KADOKAWA取締役・代表執行役社長CEOの夏野剛氏と、一般社団法人シンギュラリティ・ソサエティ代表理事の中島聡氏（オンライン参加）による特別対談から始まります。 中島氏はまず、開発者の間で急速に普及するオープンソースソフトウェア・OpenClawのリスクを指摘しました。「セキュリティに敏感な人は導入していないが、経験の浅いエンジニアや非エンジニアが大量に導入している。いつか事故が起こるでしょう」と情報流出に懸念を示しました。 特別対談「『生成AI時代』のサイバーセキュリティと経営の防衛戦」 個人情報や企業秘密は、悪意ある攻撃者からも狙われています。AIを使用したサイバー攻撃はその攻撃手法も多様化しており、フェイク（嘘）で情報を引き上げるものから、フィッシングでマルウェアを仕込むタイプまで、あらゆる手段で我々の情報を奪おうとします。 中には夏野社長を騙った差出人が社内のアドレスに向けて「会計データを出せ」と指示したという例もあり、夏野社長は「これが何万パターンと出てくると、引っかかる人も出てくるのではないか」と語ります。 そして中島氏は、Claude Codeなどのツールがファイルシステムへのアクセスをプロンプトでしか制御していないため、「プロンプトインジェクションを上手に使えば何でもやり放題できるAIが、開発者のマシンほぼ全部に入っているというもののすごい状況。すでに、APIキーがかなりの勢いで盗まれているようです」と警鐘を鳴らしました。 対策として中島氏が唱えたのは、AIが書くための新しいプログラミング言語の設計です。「プロンプトだけでAIに映像を作らせると、できたものが気に入らない時はプロンプトに戻さなければいけません。この間に何もステップがないのが非常に問題です」と指摘する中島氏。 自身が開発する映像生成プロジェクト「MulmoCast」では、まず「MulmoScript」というスクリプト言語で台本を生成させ、人間がチェックするというワンクッションを設けているとのこと。 「スクリプト言語は結局ある意味中間言語なので、その言語のインタプリタもしくはコンパイラさえしっかり作ってあれば、思いもしないものを作ってしまうとか、ファイルシステムの中身を盗んでしまったみたいな事件が起こらないよう100%コントロールできる」と説明しました。 2024年にランサムウェアの被害に遭った「当事者」である夏野氏は、「経営の観点から見ると、テクニカルな用語をどれだけしてもサイバー攻撃のリスクを排除することは絶対にできない。起こった時にどうするかを事前に準備しておくしかありません」と語りました。 そのうえで、KADOKAWAに要求された身代金問題について「絶対に僕に聞かないでください」としつつ、「身代金を払った方が安くつきました」と重い一言。 KADOKAWA 取締役・代表執行役社長CEO 夏野剛氏 一般社団法人シンギュラリティ・ソサエティ 代表理事 中島聡氏（オンライン） 笑う人や深く息をつく人など、来場者がさまざまな反応を示すなか、夏野氏は「経営者としてリスクを最小限に抑えることを考えると、身代金を払うことは一定の合理性があるし、そこは攻撃者もクレバーに金額を設定している」と実感のあるコメント。「被害に遭った場合にどうするかという現実的な議論を普段からすることが重要」だと提言します。 ここで中島氏が「身代金の支払いを違法化すると犯罪防止になりますか？」と問いかけると、夏野氏は「日本企業は身代金を払えないという認識が広まれば、日本企業を対象外にする可能性はある。選択肢としてはありだと思う」と解答。 大きな抑止力になるとする一方で、「被害に遭った経営者は最悪な状況に追い込まれる。そして攻撃のコストが低い以上、完全な抑止にはならないかもしれない。効果は非常に限定的になる可能性もあります」と、率直にジレンマを語りました。 最後に、中島氏は「みんなが使っているから安心という発想が一番危ない。今のところ大きな問題は起こっていないが、ClaudeCodeやOpenClawで事件が起きるのも時間の問題だと思います」と警告。 夏野氏は「AIの詐欺を見抜く力は人間にない。自動車や火災のように保険をつくり、みんなで互助的にやっていくしかないのでは」と提案したうえで、「常にリスクがゼロにならない前提で、ベンダーとのシミュレーションも含めた事前準備をしてください」と、経営者へのエールで締めくくりました。 GMO Cybersecurity Awards 2026 表彰式 夏野氏・中島氏のトークセッションに続いて、サイバーセキュリティ分野での顕著な功績を表彰する「GMO Cybersecurity Awards 2026」の表彰式が行われました。 GMO Cybersecurity Awards 2026 受賞者・プレゼンターによるフォトセッション サイバー犯罪対策功労賞に選ばれたのは、香川大学サイバーセキュリティセンター客員研究員の平野敏範氏。LINE APIを活用した防犯対策ツールを開発し、大阪府警や高校と連携してサイバー防犯教育を推進することで、技術教育と防犯意識の向上を同時に実現しながらセキュリティ業界の人財不足に新たな解決策を示した点が高く評価されました。 「ツールを作るだけでなく、大阪府警と防犯教室を行い、高校生と一緒に取り組むことで意識が高まった」とコメントする平野さん。四国の団体「UDONプロレス」所属のレスラーとしても活躍する平野氏は、壇上でマスクをかぶってアピールし、会場は驚きと笑いに包まれていたのが印象的でした。 香川大学サイバーセキュリティセンター 客員研究員 平野敏範氏 人財育成賞は、「International Cybersecurity Challenge TOKYO 2025」運営グループが受賞。世界から200名を超える選手・関係者が参加した国際CTF大会を官民で共催し、複雑な技術戦をアニメーションでリアルタイムに可視化するという新たな観戦スタイルを確立しました。日本の強みであるコンテンツ力を活かし、若者のセキュリティへの関心を高めた点が評価されての受賞となりましたが、代表して登壇した国家サイバー統括室の仙崎達治氏は「官民で国際的なCTF大会を共催し、日本らしさを出せた。今後もこの経験を人財育成に活かしていきたい」と今後の抱負を語りました。 「International Cybersecurity Challenge TOKYO 2025」運営グループ そして大賞を受賞したのは、サイバー防衛シンポジウム熱海前大会委員長の伊東寛氏です。自衛隊初のサイバー部隊の創設から、民間企業や経済産業省での人財育成、「サイバー防衛シンポジウム熱海」の立ち上げに至るまで、組織間の壁を取り払って実質的な官民連携プラットフォームを確立した功績が称えられました。 サイバー防衛シンポジウム熱海前大会委員長 伊東寛氏 現場運用から国家政策まで幅広く影響を与えた伊東氏は「今振り返ると、すべて一緒にやってくれた仲間の力です」と感謝を述べたうえで、「人生は出会いとご縁である」という自らの人生訓の1つを紹介。「皆さんと共に日本のサイバーセキュリティを向上させていきたい」と力強く語り、惜しみない拍手が送られました。 新会社「GMO Preferred Security」設立発表 表彰式に続き、GMOインターネットグループから新会社の設立が発表されました。 「GMO Preferred Security」は、Preferred Networks、GMOインターネットグループ、GMOサイバーセキュリティ byイエラエの3社による合弁会社で、「半導体からAIソフトウェアに至るまで、セキュアな国産AI環境を構築する」というミッションを掲げます。 壇上に上がったのは、このGMO Preferred Security株式会社で代表取締役社長を務める内田朋宏。 GMO Preferred Security株式会社代表取締役社長 内田朋宏 設立の背景として、ロボットやドローン、自動運転などAI端末の急速な普及を挙げ、「これまでのセキュリティ対策はソフトウェアやインターネット空間が中心でしたが、AI端末が社会インフラとなる今、半導体そのもののセキュリティが喫緊の課題です」と説明。国内に半導体レベルからの検証体制を持つことは、経済安全保障上の大きな意義があると示します。 続いて登壇したPreferred Networks代表取締役社長の岡野原大輔氏は「AIをセキュリティに使うだけでなく、AIインフラそのものにセキュリティを組み込む。半導体部分からAI提供まで、しっかり基盤を作っていく」と述べ、3社の強みを組み合わせることへの期待を語りました。 Preferred Networks 代表取締役社長 岡野原大輔氏 パネルディスカッション「将来戦におけるサイバー領域の様相と国家としての対策」 続いて行われたパネルディスカッションでは、Preferred Networks代表取締役社長の岡野原大輔氏、経済産業省大臣官房審議官の奥家敏和氏、NICT主席研究員の伊東寛氏、陸上自衛隊教育訓練研究本部研究部長・陸将補の小山直伸氏をパネリストに迎えました。モデレーターは、GMOインターネットグループ サイバー防衛事業推進本部「6」本部長の廣惠次郎が務めます。 最初にマイクが渡ったのは小山陸将補。ウクライナ戦争の実例を交え、現代戦がどのように進行するかを報告しました。 パネルディスカッション「将来戦におけるサイバー領域の様相と国家としての対策」 AIが台頭した現在、サイバー攻撃は単一の手段ではありません。航空システムのネットワークや電力網を遮断し、敵部隊の能力を低下させたうえでレーダーを無効化し、物理的な打撃を加えるといった「領域横断作戦」として展開されています。 GMOインターネットグループ サイバー防衛事業推進本部「6」 本部長 元陸上自衛隊 陸将 廣惠次郎 陸上自衛隊教育訓練研究本部研究部長 陸将補 小山直伸氏 物理的手段も含めた、ありとあらゆる攻撃手段や軍事行動と組み合わされるサイバー攻撃は「今後さらに高度化する」と語る小山氏。AIが搭載されている無人機についても触れ、「極めて重要な戦力の核になっていく。領域横断作戦下においていかにAIと無人機を活用していくかがポイントになるだろう」と示します。 高度に自動化されたサイバー攻撃は極めて高い軍事的影響力を持つとはいえ、AI無人機は万能な存在ではありません。データポイズニングやプロンプト攻撃、スプーフィングによる乗っ取りなど、無人機を無効化されたり逆用されたりするリスクは残るため、小山氏は「AI無人機自体がサイバー攻撃の脆弱点にもなる」と指摘しました。 表彰式に続いての登壇となった伊東氏は、NICTの観測データに基づき、ロシア・ウクライナ間のサイバー攻撃の実態を紹介。開戦と同時にロシアからウクライナへのDDoS攻撃が急増し、その1週間前には「試射」のような小規模な攻撃が観測され、さらにウクライナからロシア側へも「反撃」があったことを明かしました。 国立研究開発法人情報通信研究機構(NICT)主席研究員 ​伊東寛氏 現在は人間がAIを使って防御・攻撃を行なったり、AIを出し抜こうとしたりといった姿が見られますが、「これからはAI対AIの時代になる。AIは間違いなくこれからのサイバーセキュリティやサイバー戦でも使われるようになる」と確信を示します。 こうした課題について、奥家氏は国の立場から打てる対策を説明。2019年にはサイバー攻撃と物理が一体化する現代戦において生じるセキュリティホールの対策として「サイバーフィジカルセキュリティフレームワーク」を策定し、2021年にはサプライチェーンへの攻撃対策を進め、これらの対策に加え、2025年にはサイバー対処能力強化法を制定するなど政府はサイバー空間の安全性に努めていますが、奥家氏は依然として3点の課題があると語ります。 経済産業省大臣官房審議官 奥家敏和氏 1点目はフレーミングのオペレーション能力です。「実際に特定して攻撃元を叩くフレーミングがあるということと、有事の際にそのフレームを使って対処する能力は全く別」（奥家氏）であり、この能力を確立すべくさまざまな準備をしているところだと示しました。 2点目は物理的なダメージ制御の安全性を高めるOT（Operational Technology）について。OT領域への対応は各国で課題となっていますが、奥家氏は「OTへのダメージをどう抑えて、社会的なダメージを最小化していくのか」がポイントだとしています。 3点目はサプライチェーンにおけるセグメンテーションです。流通網が広がる中で、アタックポイントとなりかねない地方自治体や中小企業が狙われた際は、「入り口をふさぐ」ための社会的なセグメントをどうかけていくのかが課題になると説明します。 「技術トレンドの発展に伴って攻撃は苛烈化していますし、どういった形であっても新技術の導入はマストです」と語る奥家氏。その一方「こうした新技術を、私たちがどうやって社会的に飲み込んでいくのかという課題に対処しなければならない」と、新技術が社会的に受け入れられるためのリズムを作る必要があるという認識を述べました。 岡野原氏は半導体とAIモデルの双方で、「使う時」「作る時」の両面からサイバー対策が必要だと主張します。 Preferred Networks 代表取締役社長 岡野原大輔氏 半導体においては信頼できるサプライチェーンの構築や、品質などをさまざまな形で検証できる仕組みりが必要だとしたうえで、「設計段階にはなかった回路が入って、そこにマルウェアが入っていた、というようなことが起きらないとも限らない」と危険性を訴えました。 同様の懸念は、AIでも起こり得ます。Preferred NetworksではフルスクラッチでLLMの製作に取り組んでいますが、学習データに悪意あるプログラムなどを仕掛けられる可能性もあるため、「データの部分から学習まで、どうやって信頼性のあるチェーンをつないで作っていくかが重要になります」と示しました。 知らずにマルウェアを埋め込まれ、意図しない挙動で情報漏洩などが起こりうると警鐘を鳴らす岡野氏。「今動かしてるモデルが本当に安全な状態で動いているかどうか、特定の条件を満たした場合に攻撃されやすい状態にならないかは常時監視しなければなりません」と、サイバー空間の安全性を高める仕組みの必要性を提示しました。 パネルの締めくくりでは、伊東氏が「最後はやっぱり人間。信頼し合える人間関係を作ることが一番大事」と語り、奥家氏も「お互いをリスペクトし、フレームワークを共有することでネットワークができる」と同調。 岡野原氏も、「技術だけではなく、体制やコミュニティを作っていくことが必要」だと述べます。そして小山陸将補は国際連携においてもシステム・プロシジャー・ヒューマンネットワークの3つが鍵であるとし、とくに人間関係の構築の難しさと重要性を強調して講演を終えました。 パネルディスカッション「我々を狙うサイバー攻撃の実態——能動的サイバー防御は『犯罪対策』を変えられるか」 最後のセッションでは、日本プルーフポイント チーフエバンジェリスト・警察大学校講師の増田幸美氏、FFRIセキュリティ代表取締役社長の鵜飼裕司氏、GMOサイバーセキュリティ byイエラエ GMOサイバー犯罪対策センター局長の福森大喜をパネリストに、MUFG GMO セキュリティ代表取締役副社長の平野賢一がモデレーターを務めました。 パネルディスカッション「我々を狙うサイバー攻撃の実態」 講演の冒頭、増田氏はプルーフポイントのデータを基に「全世界で2025年に検知された新種メール攻撃のうち、82.8%が日本をターゲットにしている」という衝撃的な事実を公開。 会場がどよめく中、「攻撃者は端末のIPアドレスやOSの言語設定などで日本人を識別し、日本人だけをフィッシングサイトへ誘導。それ以外のユーザーには正規サイトへリダイレクトする」という巧妙な手口を明らかにしました。 日本プルーフポイントチーフエバンジェリスト 警察大学校講師 増田幸美氏 生成AIが突破したのは、言葉の壁だけではありません。増田氏は「LINEグループへの誘導など、日本の文化を知らなければ実践できない手法も生成AIが可能にしている」と注意喚起します。 さらに増田氏は、社長の声を再現した音声に加えて、発信者番号まで社長の番号に偽装するという高度なCEO詐欺事例がすでに5社から報告されていると紹介。「生成AIで日本語の壁を越えられるようになった今、日本企業の持つ知的財産や個人情報はアンダーグラウンドで高値で取引されている」と危機感を示しました。 またAIの悪用とメール攻撃について、シングルサインオンのリスクも示されました。現在、多くのクラウドサービスはメールアドレスとパスワードでログインできるようになっていますが、メールアカウントが乗っ取られた場合は「その人が行けるシステムのどこまででも攻撃できる」（増田氏）状態になりかねないのです。 増田氏はこうした現状について、「攻撃者が欲しいデータはクラウドにある。APIでどんどん接続しようという流れがありますが、アカウントアイデンティティの大事さはこれからもっと増していくでしょう」と見通しを示しました。 鵜飼氏は研究開発に携わる立場から、今後の展望についての議論を紹介しました。具体的には、脆弱性の自動発見精度が向上して発見コストが下がったことや、AIによるペンテストの自動化技術が実際の攻撃に転用されることで、とるべき防御技術についての議論が起こっているとしています。 FFRIセキュリティ代表取締役社長 鵜飼裕司氏 こうしたAIによる脆弱性発見コストの低下が「攻撃のパラダイムシフト」を引き起こしていると指摘。「昔は職人芸だったものが、AIでそこまで頑張らなくてもできてしまう世界がもう来ている」と述べ、危機感をあらわにしました。 鵜飼氏の発言を受け、福森は2026年10月から運用が開始される能動的サイバー防御の適用範囲に触れ、「IoTボットネットから国家レベルの攻撃まで対象が幅広く、どの段階で発動できるのかが課題」と問題を提起。「たとえばランサムウェアで10億円要求されたというケースを考えたとき、このレベルで能動的サイバー防御をどこまで発動できるかが課題だと思いますね」と実感を述べます。 GMOサイバーセキュリティ byイエラエ GMOサイバー犯罪対策センター 局長 福森大喜 増田氏は「能動的サイバー防御はミサイルの根元を叩きに行くものではない。そこを壊しても作り直されるだけなので、アメリカのDefend Forwardのように、インターネットの接続点で対処する方がはるかに現実的」と指摘しました。 こうしたサイバー犯罪の話題は、現在のイラン情勢にも及びます。増田氏は先のセッションで小山氏の語った「物理攻撃とサイバー攻撃の融合」が実践されていることに触れ、ニュースサイトの改ざんや通信インフラの遅延に加え、市民の祈祷時間を管理するアプリのハイジャックがミサイル攻撃とほぼ同時に行われた事実を示しました。 このアプリはイラン国軍の兵士の多くが使用しているものであり、増田氏はアメリカが事前にハッキングして準備を整えていた点を指摘。「1つ1つの事象を個別のサイバー犯罪としてとらえるのではなく、国家安全保障に関わる全体的な問題」だと訴え、能動的サイバー防御がこうした問題に対処できるようになってほしいと期待を込めました。 最新のセキュリティ動向からイラン情勢まで、多くの情報が展開された本セッション。増田氏は「日本が一番攻撃を受けているということは、一番攻撃情報を持っているということ。他国への情報提供で一目置いてもらえるチャンスでもある」と前向きな姿勢を見せます。 鵜飼氏は「この1年半で、サイバー空間は大きく変化しました。これからやるべきことはものすごく増えていきますが、しっかり力を合わせて乗り切っていきたい」と意気込みを語ります。 MUFGGMOセキュリティ 代表取締役副社長 平野賢一 そして福森は「技術面やマネジメントなど、さまざまなレベルでまだまだできることがある。だからこそ、今後は絆を深めながら進んでいきたい」と、官民学の壁を越えた連携の重要さを強調し、会場から大きな拍手が送られました。 アフターパーティー 全セッション終了後、GMO Yours・フクラスにてアフターパーティーが開催されました。GMOインターネットグループ 取締役 グループ副社長執行役員・COO西山裕之が「人が大事」と挨拶したのに続き、サイバー防衛事業推進本部「6」本部長の廣惠次郎が乾杯の音頭を取りました。 「6（SIX）はサイバーを意味する世界共通の軍事用語。ここにいる皆さん全員がSIXの仲間です。この人間関係を大事にしていきたい」と語りかけたのち、GMOインターネットグループ恒例の「完勝！」の掛け声で皆がグラスを掲げ、大きな盛り上がりを見せた会議を締めくくりました。 産官学の第一線で活躍する多彩な登壇者が一堂に会し、AI時代のサイバーセキュリティの現在地と未来を多角的に議論した「第3回GMO大会議・春 サイバーセキュリティ2026」。AI時代のセキュリティの在り方についての熱い議論や講演から得られた知識や知見は、来場者の方々や我々GMOインターネットグループの大きな財産になりました。 GMOインターネットグループは「ネットのセキュリティもGMO」のスローガンのもと、安心・安全なデジタル社会の実現に向けてこれからも歩みを進めてまいります！ イベントレポート前編はこちら https://www.youtube.com/live/L4xP-5K7lBQ?si=g2RHtTF5K2S2V_-8 アーカイブ映像はこちらから

AIコーディングエージェントによって、実装のスピードは確かに上がりました。設計し、試し、修正する。その試行回数を増やせることは、AI駆動開発の大きな価値です。一方で、コード品質のばらつきや設計の揺れといった課題も見えてきました。そこで私たちは、AIの出力品質を人の注意力ではなく、構造で支える仕組みとして「ハーネスエンジニアリング」を導入しました。本記事では、その実践内容を紹介します。 はじめに こんにちは。GMOインターネットの平野です。 ConoHa VPSではMCP（Model Context Protocol）サーバーを、Claude Codeを活用したAI駆動開発で構築しています。この開発スタイルをしばらく続けてきて、AI コーディングエージェントに実装の多くを任せ、開発スピードはたしかに上がったと実感しています。 これは単に人間がコードを書く量が減る、という話ではなく、設計して、試して、修正する。その往復が速くなり、試行回数を増やせるのが大きいと感じています。 一方で、運用を続けるうちに、見過ごせない課題もはっきりしてきました。AIが出力するコードの品質に、どうしてもばらつきが出でしまいます。ファイルごとに実装パターンが少しずつずれたり、命名規約に揺れが出たり、アーキテクチャ境界を越えたimportが紛れ込んだりする。しかも、そのズレを最後に拾うのは、PRレビューをする人間の注意力でした。この状態だと、AIに任せるほど開発は速くなる一方で、品質保証のしわ寄せが人間に集中してしまいます。 そこで、AIの出力品質を人の頑張りではなく、構造で担保する仕組みを整えました。そのベースに置いたのが、ハーネスエンジニアリングという考え方です。この記事では、その実践内容を紹介します。 ハーネスエンジニアリングとは ハーネスエンジニアリングは、AI コーディングエージェントを“自由に走らせる”のではなく、守るべき制約を明示し、逸脱したら検知・修正・停止できるようにする考え方です。名前のとおり、「手綱（harness）」のメタファーに近いものです。 中心になるのは、次の 3 つです。 コンテキストエンジニアリング: AIに「何を守るべきか」を正しく伝えるアーキテクチャ制約: 不変条件を機械的に検証し、違反をブロックするガベージコレクション: ルール体系そのものの劣化を検知し、鮮度を保つ この考え方を、「ドキュメント → AI セマンティック → CI → 構造テスト」という 4 段階のエスカレーションラダーとして実装しました。現在は、12 カテゴリ・48 ルールをこの体系で管理しています。 カテゴリー内容ルール数Aファイル構造3Bクライアントモジュール6Cスキーマ4Dレスポンスフォーマッター5Eテストファイル6FJSDoc3Gインポートルール4H命名規則4Iアーキテクチャ境界5Jコード衛生2Kセキュリティ・品質3Lドキュメント整合性3 4段階エスカレーションラダー このフレームワークの核になるのは、ルールの執行レベルを段階的に引き上げることです。すべてのルールは、まずL1のドキュメントから始めます。そのうえで、違反の頻度や、自動検出のしやすさに応じて、より強いレベルへ昇格させていきます。 最初からすべてをCIやテストに押し込むわけではありません。まずは言語化し、繰り返し問題になるものだけを、より強い執行手段へ移していく。この段階設計が、実際に回る仕組みをつくるうえで重要でした。 L1: ドキュメント: すべてのルールの出発点 最初の段階では、ルールを15個のパターンファイル（harness/patterns/*.md）に分けて定義しています。各ファイルには YAML フロントマターを持たせ、enforcement-levelやrelated-rulesといったメタ情報も一緒に管理しています。つまり、ルールを単なる読み物として書くのではなく、あとから機械的に扱える前提で整理している、ということです。 ここで大事なのは、「何を守るべきか」を曖昧にしないことです。AIに品質を求める前に、人間側が品質基準を明文化しておく必要があります。地味に見える作業ですが、ここが曖昧だと、その先の自動化はどこかで破綻します。 L2: AI セマンティック: AIの判断力を執行に使う 機械的に判定しづらいルールは、AI のセマンティックな理解を使って執行します。 開発時（予防）: CLAUDE.mdにルールを記述し、Claude Codeが開発中に参照するPR時（検知）: Claude Code Review CIが差分をレビューし、違反を指摘する このレベルの強みは定量化しにくい品質基準まで扱えることです。 たとえば、「APIレスポンスは、利用者が次のアクションを判断するのに必要な情報だけを返す」「エラーメッセージには、何が起きたかだけでなく、次にどうすればよいかも含める」といった基準です。こうしたものはlintや単体テストでは扱いづらい一方で、実際の使い勝手には大きく影響します。 だからこそ、これらを単なる“書き方の好み”で片づけず、品質基準として AI に共有しておくことが重要になります。 L3: CI ツール: 機械的に検出できるものは止める 違反が繰り返し発生し、しかも機械的に検出できるルールは、CI に移して自動でブロックします。 ツール検出対象CI種別Biomeフォーマット・リンティングblockingdependency-cruiser循環依存・アーキテクチャ境界blockingknip未使用ファイル・未使用エクスポートblockingnpm audit高リスク脆弱性blockingjscpdコード重複advisorystrykerミューテーションスコアadvisory ここでは、違反時にマージを止めるblockingと、改善の参考情報として扱うadvisoryを分けています。この線引きは、現場で運用するうえで意外と重要です。今すぐ直さないといけないものと、継続的に改善していくものが混ざると、だんだん全部がノイズになってしまうからです。 L4: 構造テスト: アーキテクチャの不変条件を固定する 最上位のL4では、architecture.test.tsに23個のアーキテクチャ不変条件をVitestで実装しています。npm testを実行するだけで、たとえば次のようなプロジェクト固有ルールを検証できます。 ファイル名が命名規約に従っているかスキーマ定義に.strict()が付いているかエクスポート関数がcamelCaseに従っているか ここまで来ると、ルールは「読めばわかるもの」ではなく、破ったらテストが落ちるものになります。レビュー担当者の気づきに頼るのではなく、構造として守られる状態をつくれるのが、このレベルの大きな価値です。 開発フローの中で効かせる: Claude Code Hooks 4 段階のラダーは、主に CI やテストで効く仕組みです。ただ、実際に運用してみると、それ以上に効果を感じたのは、CIに届く前のローカル開発段階でもルールが作用することでした。そこでClaude Codeの Hooksを使い、3つのガードを設定しています。 Hookタイミング役割harness-guardファイル編集前ハーネスファイル編集時に「Architecure Decision Record（ADR）の作成が必要かもしれない」と警告biome-autofixファイル編集後Biomeの自動修正を即時適用Stop promptAI作業完了時typecheck/testの実行漏れやKDR検討漏れを確認 これによって、AIがコードを書いた直後にフォーマットが整い、作業を終えようとした時点でテスト実行漏れも指摘されます。CIで落ちてから気づくのではなく、開発ループの中でその場で修正される。この即効性は、実際に回してみるとかなり効きました。 昇格の判断と実例 ルールを上位レベルへ昇格させる最終判断は人間が行います。ただし、その判断材料の収集は自動化できると考えています。 現在実装を進めているのが、Claude Code Review CIが付与するpattern-violation:*ラベルを週次で集計し、3回以上検出されたL2ルールについてGitHub Issueを自動作成するエスカレーショントラッカー（escalation-tracker.yaml）です。これが稼働すれば、「このルールはL3に上げるべきか」「構造テストにすべきか」を、開発者がデータに基づいて判断しやすくなります。判断の経緯は、Architecure Decision Record（ADR）として残す運用を想定しています。 実例をひとつ挙げると、プロジェクト初期にはCODING_PATTERN.mdという 681 行の単一ファイルでルールを管理していました。しかし、この形だと AI がコンテキストとして読み込むコストが高く、メンテナンスもしづらい。そこで16個の独立したパターンファイルに分割し、それぞれにメタデータを付ける設計へ移行しました。 これは単なるファイル整理ではありません。AIが参照しやすく、人間も保守しやすいルール体系へ作り直した、という意味で大きな転換でした。 エントロピー管理: ルールは書いて終わりではない ルールは、一度作れば終わりではありません。むしろ時間がたつほど、現場に合わなくなったり、形骸化したり、守る意味が薄れたりします。放っておくと、品質を守るための仕組みそのものが、現場の負債になっていきます。 そこで現在、週次のエントロピースキャンを GitHub Actions で定期実行する仕組みの導入を検討しています。具体的には、次のようなチェックを計画しています。 パターン鮮度チェック: 各パターンファイルの最終レビュー日を90日の閾値で確認する依存関係ドリフトの検出: npm audit、knip、dependency-cruiserを PR 時以外にも定期実行する違反検出時の自動起票: 問題をGitHub Issueに起票し、対応漏れを防ぐ また、このフレームワークがどう変化してきたかは、Architecure Decision Record（ADR）として残しています。エスカレーションラダーを導入した理由、L3ツール群の選定基準、どのルールをどのタイミングで昇格させたのか。そうした判断の背景まで残しておくことで、運用が属人化しにくくなります。 仕組みを続けるうえで大事なのは、「良いルールを作ること」だけではありません。そのルールが今も有効かを見直し続けることだと考えています。 まとめ AI 駆動開発で品質を担保するうえで大切なのは、AI を過度に信用することでも、逆に必要以上に疑うことでもありません。AIが守るべき制約を人間側が設計し、その制約を段階的に執行できるようにすることです。今回紹介したハーネスエンジニアリングの要点は、次の3つに整理できます。 1. ルールは段階的に強くする 最初はドキュメントとして言語化し、必要に応じてAIレビュー、CI、構造テストへと昇格させる。こうすることで、運用コストと実効性のバランスを取りながら、ルールを育てていけます。 2. 定量化しにくい品質も扱う Taste Invariants──リンターや構造テストでは検出しづらいが、UXや設計意図に直結する品質基準を、AIが検知・遵守できる形で明文化した不変条件──のような基準を言語化して共有しておくことで、機械的な検証だけでは拾いにくい品質も扱えるようになります。使いやすさやわかりやすさのような価値は、こうした層で効いてきます。 3. ルールそのものも保守対象にする 週次スキャンやArchitecure Decision Record（ADR）を通じて、ルールの鮮度と判断の背景を継続的に管理する。これをやらないと、どんなに立派な仕組みも、時間とともに形だけのものになってしまいます。 今後は、Claude Code Review CIで検出された違反ラベルを集計し、昇格候補のルールを自動で見つける仕組みや、エントロピースキャンで見つかった問題を自動修正につなげるワークフローも整えていく予定です。 AIコーディングエージェントは、これからさらに進化していくはずです。だからこそ、それを支える“手綱”の側も、固定されたルールとして置いておくのではなく、実際に使いながら育てていく必要と考えています。 ConoHa VPS MCPサーバー はこちらからご利用できます。 ConoHa VPS MCPは、ConoHa VPSの公開APIを日本語で簡単に操作できるオープンソースのModel Context Protocol (MCP) サーバーです。Claude Code、GitHub Copilot、ClineなどのAIエージェントと連携することで、自然言語によるVPS・オブジェクトストレージの操作が可能になります。ぜひ使ってみてください! また、ハーネスエンジニアリングについての弊社の取り組みについて、インタビュー記事も公開されました。よかったら合わせてご覧いただけますと幸いです。

はじめに 現在、弊社のコールセンターでは、従来型音声AI(音声→テキスト→回答生成→音声変換)を導入しています。このようなAIは、お客様の音声をテキストに変換し、AIが処理した後、再び音声に変換するという流れでした。 それに対し、昨年話題となったSpeech-to-Speech型のリアルタイムAI API(以下、S2S API)は、音声から直接音声で回答を生成できるようになり、より自然な会話が可能になりました。そこで、弊社でもS2S APIの導入を検討することになりました。 既存電話システムの仕組み まず一般的なVoIPシステム(IP電話)の仕組みですが、以下の2つのプロトコルで構成されています。 SIP(Session Initiation Protocol) 役割: 通話の開始、終了、転送などの制御特徴: 音声データ自体は送らない RTP(Real-time Transport Protocol) 役割: 実際の音声データの転送特徴: SIPとは別経路で送信される [電話システム] --SIP(制御)--> [相手先] --RTP(音声)--> このように、制御と音声が分離された2チャネル構成が電話システムの特徴です。 S2S APIを利用する上での3つの接続方式 S2S APIは、主に3つの接続方式に対応しています。 ※対応状況はサービスによって異なります。導入するS2S APIの仕様を確認してください。 1. WebSocket 双方向通信チャネルを提供するプロトコルです。 通信モデル: [クライアント] <--WebSocket(制御+音声)--> [S2S API] HTTPでハンドシェイク後、TCP接続を維持制御信号と音声データを単一チャネルで送受信実装がシンプルサーバー間（サーバー to サーバー）での処理に向いている ⚠️ 注意: WebSocketはTCPベースのため、ネットワーク上でパケットロスが発生した場合、再送処理により遅延が増大するリスクがあります。 2. SIP 電話システムと同じシグナリングプロトコルです。 通信モデル: [電話システム] <--SIP+RTP--> [S2S API] 既存のVoIPシステムと同じプロトコルSIP(制御) + RTP(音声)の2チャネル構成電話システムとの親和性が高い 3. WebRTC リアルタイム通信のためのフレームワークです。ブラウザ間のP2P通信向けに設計されましたが、S2S APIとの接続ではクライアントとAPIサーバー間の通信に利用します。 通信モデル: [ブラウザ] <--WebRTC P2P--> [S2S API] SRTP(Secure RTP)でメディア転送超低遅延(50-150ms)ブラウザから直接接続可能 3つの接続方式の比較 項目WebSocketSIPWebRTC遅延100-300ms（パケットロス時はさらに増大）100-300ms50-150ms実装難易度低中高電話システム連携変換必要直接可能変換必要ブラウザ対応○×○主な利用用途サーバー間処理電話システム直結Webブラウザ通話メリット実装が簡単デバッグしやすい既存インフラ活用変換不要低遅延デメリットTCP特性上、パケットロス時に遅延増大リスクカスタマイズ性低API実装に依存実装複雑ネットワーク環境によっては追加のインフラ構成が必要になるケースあり ※S2S APIサービスによって対応している接続方式は異なります。 コールセンターでの接続方式の選び方 コールセンターとS2S APIを繋ぐ場合、要件に応じて適切な接続方式が変わります。 既存の電話システムと直接接続する場合: SIP接続 既存インフラをそのまま活用できる 電話システムと同じプロトコル追加の変換処理が不要 統合が容易 電話番号からの着信に対応既存の通話フローに組み込みやすい 安定性 電話業界で長年使われている実績 接続イメージ: [お客様の電話] → [電話システム] --SIP/RTP--> [S2S API] 柔軟性やセキュリティを重視する場合: SBC経由WebSocket/WebRTC接続 音声処理のカスタマイズやセキュリティ管理を細かく行いたい場合は、SBC(後述)を経由してWebSocketやWebRTCで接続する方式が適しています。 接続イメージ: [お客様の電話] → [電話システム] --SIP/RTP--> [SBC] --WebSocket/WebRTC--> [S2S API] Webブラウザから利用する場合: WebRTC接続 電話システムを介さず、ブラウザから直接S2S APIと通話する場合は、WebRTC接続が低遅延で最適です。AIアバターなどで回答させたい場合はこちらの方式が適しています。 接続イメージ: [Webブラウザ] --WebRTC P2P--> [S2S API] 参考情報: SBCとは 実際の運用では、電話システムとS2S APIの間にSBC(Session Border Controller)を配置するのが一般的です。 SBCの役割 SBCは、異なる通信モデル間の「橋渡し」をする機器です。 主な機能: プロトコル変換: SIP ⇔ WebSocket/WebRTCセキュリティ制御: アクセス制限、暗号化音声処理: コーデック変換、ノイズ除去、録音柔軟性: 複数のS2S APIサービスへの対応 SBC経由の構成: [電話システム] --SIP/RTP--> [SBC] --WebSocket/WebRTC--> [S2S API] SBCを挟むことで、セキュリティ強化や柔軟な音声処理が可能になります。 まとめ コールセンターでS2S APIを繋ぐ接続方式は主に3つあります: WebSocket: 実装がシンプル、サーバー間処理向き（ただしTCPの特性上、パケットロス時は遅延増大に注意）SIP: 電話システムと親和性が高い、直接接続可能WebRTC: 低遅延、ブラウザ向き コールセンターでは、要件に応じて接続方式を選択します: 既存インフラ活用 → SIP接続柔軟性・セキュリティ重視 → SBC経由WebSocket/WebRTC接続Webブラウザ利用 → WebRTC接続 この記事で紹介した技術は、現在弊社内で導入に向けた検討・検証を進めています。今後お問い合わせの際に「なんだかスムーズだな」と感じることがあれば、このブログの技術が生かされているかもしれません。そんなことをふと思い出していただけたら嬉しいです。

GMOインターネットグループは、2025年12月21日に行われた学生向けAIキャリアフェス「AIチャレンジャーズフェス2025」にトップスポンサーとして協賛しました。会場となったGMO Yours・フクラスにはAIに熱中する学生150名が集結。基調講演、企業プレゼンテーション、パネルディスカッション、AIキャリアブースと、盛りだくさんのコンテンツをお楽しみいただきました。会場の熱気や各セッションの見どころを3回にわたりお届けする協賛レポート、後編です。 パネルディスカッション｜AI時代を生き抜く力─現場から見た働き方と学びの変化 イベント後半では、パネルディスカッション「AI時代を生き抜く力」が行われました。 生成AIの進化によって、教育、開発、事業推進の現場ではすでに大きな変化が起きています。本セッションでは、それぞれ異なる立場でAIと向き合う登壇者が集い、AI時代に求められる力やキャリアのあり方について議論が交わされました。 登壇したのは、教育系YouTuberとして活躍するヨビノリたくみさん、ソフトバンク株式会社でAI戦略を担当する木口佳南さん、GMOインターネットグループでAI活用推進を担う内野皓太、そしてDeNAでエンジニアとしてAI関連プロダクトに携わってきた島岡秀知さんです。 AI登場、働き方はどう変わった？ 冒頭では、AIが実装・生活・ビジネスへと浸透してきたこの1〜3年で、働き方や学び方がどのように変化したのかという問いが投げかけられました。 ヨビノリさんは、教育の現場において「教え方そのものが劇的に変わったわけではない」としつつも、授業準備や情報収集の効率は大きく向上したと語ります。たとえばノーベル賞発表直後のように、日本語での情報が不足する場面でも、生成AIを活用することで正確な一次情報に素早くアクセスできるようになった点を挙げ、即時性が求められる場面での有用性を強調しました。 木口さんはAIエンジニアとしての視点から、「コードを書く力」よりも「コードを読む力」の重要性が高まっていると指摘。「AIが出力したコードの意図を理解し、改善点を見極める力が求められるようになり、AIの登場によってエンジニアとしての役割認識そのものが変わってきた」と振り返りました。 こうした流れを受けて、GMOインターネットグループでAI活用推進を担う内野は、生成AIが普及し始めたタイミングで入社した自身の経験を踏まえ、AIが「できる仕事の幅」を大きく広げていると語ります。 内野は2023年に「新卒年収710万プログラム」（※）で入社後、GMOインターネットグループ全体のAI活用推進プロジェクトや「AI 熊谷正寿」用のデータセット作成など、AI領域全般を担当してきました。ただし、職種としては非エンジニア。そんな内野のようなバックボーンであっても、AIの力を借りることで、これまで関われなかった領域の仕事を形にできるようになったといいます。 ※既存の枠組みに捉われない自由な発想で新しい事業やサービスを生み出すなど、高いパフォーマンスが期待できる優秀な人財に対して年収710万円（2年間）をお約束する、GMOインターネットグループならではの取り組み。 GMOインターネットグループ　内野皓太 また内野は、社内で起きている変化として、「これまでエンジニアに頼んでいた作業を、自ら自動化してしまう人が増えている」点を挙げました。小さなツールや仕組みを自ら作って業務を改善していく動きが広がり、会社全体が「作る人が増えていく」方向へと変化してきたと言います。 さらに、こうした変化の先に、「そもそもこの手作業は必要なのか」と業務プロセスそのものを見直す発想が生まれていると指摘。長い歴史を持つ企業では、一種の「慣習」として続いてきた業務も少なくありません。そんななか、AIを楽しみながら使う人たちが仕組みごと変えていく動きが生まれていることは、大きな前進だと強調しました。 最後に島岡さんは、エンジニアの立場から、AIによって設計と実装のバランスが変わった点に言及します。コード生成の効率化によって、設計により多くの時間を割けるようになり、設計段階での検討や試行錯誤の質が高まっていると語りました。また、AIを活用することで複数のタスクを並行して進められるようになり、エンジニアでありながらプロダクトマネジメントやマーケティングにも関与できる働き方が可能になっているとのことです。 市場価値をどう高めるか：AI時代に求められる「強み」とは？ 続いて議論は、学生からの関心も高い「市場価値」というテーマへと移りました。AI時代に社会へ出ていくにあたり、どのような能力を持つ人が価値を発揮できるのでしょうか。 木口さんはまず、「中途半端なスキルはAIに代替されやすい」という実感を率直に語りました。エンジニアであれば「少しコードが書ける」だけでは差別化が難しく、「この分野の、この設計ならこの人が強い」と言えるレベルまで特化することが重要になる。そのうえで、AIを活用しながら価値を高めていく流れが、すでに現場で起きていると指摘します。 これに対してヨビノリさんは、「AIができないこと」を無理に探す必要はないのではないか、と話します。時代の変化により、仕事の形は変わり続けるかもしれない。でも、自分が本当にハマれるものに特化し続けていれば、形を変えながら生き残っていける。自身がYouTubeに没頭してきた経験を例に挙げながら、「好きで続けてきたことが、結果として今につながっている」と緊張を和らげます。 教育系YouTuber　ヨビノリたくみさん 島岡さんは、より事業寄りの視点から、市場価値を構成する要素を整理しました。事業を成り立たせるために必要な要素は大きく三つあり、「ドメインのエキスパートになること」「作ること」「売ること」。この三つのどれかを強みにできれば、活躍の余地は大きく広がると述べます。特に若い世代は、新しいドメインやSNS、発信力といった点で有利な立場にあることも強調しました。 DeNA　島岡秀知さん こうした流れの中で、GMOインターネットグループの内野は、自身の立場を「ゼネラリスト寄りで、いつ淘汰されるかと怯える日々だ」と話し、参加者の笑いを誘います。そのうえで、AI時代において重要になるのは特定の作業を一人で完結させる能力ではなく、「人を巻き込み、適切に依頼し、期待値を調整する力」だと話しました。 内野は「一人でできる仕事には限界がある」と前置きしつつ、人に指示を出す力や、成果物に対して改善点を具体的に伝える力が、今後ますます重要になると指摘。エンジニア職・ビジネス職を問わず、AIはむしろそうした力を鍛える存在になるのではないか、という見方を示します。 その具体例として挙げたのが、日常的な「お店探し」のエピソードでした。お店の候補をAIに出させる場合、生成結果のうち、「5件のうち2件は違う」と判断し、自分で入れ替える。あるいは、AIに条件を与えて調べなおさせる。これは、食事相手の希望や好みを把握している、AIが出した候補のお店に行ったことがあるなど、判断基準・経験があるからできます。 このように、AIや人に何かを依頼するとき、期待値や前提条件を整理し、自分なりの判断軸を持って結果を評価できるかどうか。その力こそが専門性や経験に裏打ちされた「人間の」価値であり、期待値を言語化し、調整を重ねていく力が、AI時代にはより一層問われると語りました。 この点について島岡さんも同調し、「AIをうまく使える人は、AIがない時代でも仕事ができる人」という見解を示します。プロンプト設計やAIへの指示は、本質的には「人にタスクを渡す力」と変わらず、条件整理や目的設定といったコミュニケーションの基本は、時代が変わっても重要であり続けると補足しました。 学生のうちに何をすべきか：AI時代を見据えた時間の使い方 議論の終盤では、「学生のうちに何をやっておくべきか」という、より実践的なテーマが投げかけられました。 ヨビノリたくみさんは、「心が動いたものに対して、受け手で終わらず、自分で手を動かすこと」の大切さを語りました。生成AIを見て「すごい」で終わるのではなく、「自分で使い、作ってみる」。流行や技術の登場そのものを、挑戦のきっかけにしてほしいと話します。 木口さんは、AI時代を学生として過ごしてきた立場から、自身の学生時代を振り返ります。 大学の授業と並行しながら、業務委託やインターンを複数社掛け持ちし、研究・学会発表・実務を同時並行で進めてきた経験は、結果として「自分がどの領域で戦えそうか」を見極める助けになったといいます。社会人になると、どうしても関われる領域が限定されてしまうからこそ、学生時代のうちに越境し、多様な現場に触れておくことの価値が強調されました。 ソフトバンク株式会社　木口佳南さん こうした流れを受けて、GMOインターネットグループの内野は、「おじさん的な話」と「今日からできる話」をユーモラスに語り始めました。 まず前者として、「自分が本当にやりたいと思ったことがあるなら、後悔が残らないくらい本気で向き合ってほしい」と語ります。自身がコロナ禍の影響で、思うように動けなかった学生時代を経験したからこそ、今、自由に動ける時間の価値を強く実感しているといいます。 そのうえで、より具体的な行動として挙げたのが、「AIを徹底的に使い倒すこと」でした。 学生という、失敗しても誰にも怒られない環境の中で、AIを相手に試行錯誤を重ねる。「サークル活動や身近な不便を解消するツールづくりなど、小さなもので構わないので、どんなものが欲しいかを考え、指示を出し、エラーを踏み、使いにくさを改善し成果物を作る練習を、是非低コストでしてほしい」と話しました。 島岡さんは、「やるべきこと」に追われがちな学生時代の心境に共感を示しつつ、「いつか必要そうだから」という理由で学んだことは、意外と身につかないと明かします。「今は何事も参入コストがすごく下がっているので、もちろんAIも活用しながら、まずは何かが必要になる状況を作る。そのうえで、『これが必要だから学ぼう』というタイミングが来たらしっかり学ぶのがおすすめ」とのことでした。 セッションの締めくくりとして内野は、「AI時代であっても、『この人と一緒に仕事をしたい』と思われることが何より大事だ」と語りました。自分を無理に変えるのではなく、自分の価値観やセンスを磨き、それを周囲に伝えられる存在になること。その積み重ねが、結果として市場価値につながっていく——そんなメッセージで、パネルディスカッションは幕を下ろしました。 おわりに 3回にわたるレポートをご覧いただき、誠にありがとうございました！AIとともに変化し続ける時代の最前線で、GMOインターネットグループはこれからも魅力あふれる学生の皆さんのチャレンジを応援していきます！ 前編（協賛レポート1話目）はこちらから中編（協賛レポート2話目）はこちらから

GMOインターネットグループは、2025年12月21日に行われた学生向けAIキャリアフェス「AIチャレンジャーズフェス2025」にトップスポンサーとして協賛しました。会場となったGMO Yours・フクラスにはAIに熱中する学生150名が集結。基調講演、企業プレゼンテーション、パネルディスカッション、AIキャリアブースと、盛りだくさんのコンテンツをお楽しみいただきました。会場の熱気や各セッションの見どころを3回にわたりお届けする協賛レポート、中編です。 企業プレゼンテーション｜GMOインターネットグループ 専務執行役員 内田朋宏 第一部の企業プレゼンテーションでは、GMOインターネットグループを代表してGMOインターネットグループ グループ専務執行役員（米国公認会計士）内田朋宏が登壇し、グループの成り立ちから現在注力しているAIロボティクス事業まで、幅広い取り組みをご紹介しました。 GMOインターネットグループは1995年創業。今年で30周年を迎える総合インターネット企業グループで、上場企業12社を中核とする連結124社で構成されています。上場会社の時価総額を単純合算すると約1.6兆円、パートナー（従業員）は現在8,000名。そのうち約6,000名が国内に在籍し、さらに4,500名が渋谷拠点で働いています。 経営の特徴として挙げられたのが、「GMO」という統一ブランドのもと、共通の志と価値観を持つ起業家が自律的に経営を行う「グループ経営」です。GMOインターネットグループでは、権限分散型の経営スタイルによって迅速な意思決定を可能にし、変化の激しいインターネット業界において成長を続けてきました。 GMOインターネットグループ グループ専務執行役員　内田朋宏 事業面では、国内シェアのうちドメインでは8割、ホスティングでは6割といったナンバーワンサービスを抱えるほか、決済分野では年間約20兆円の取扱高を誇るなど、インターネットインフラを支えています。とりわけ、近年成長を続けるネット銀行では、毎月設立される約1万社の新規法人のうち、半数近くがGMOのネット銀行を利用しています。 こうした成長を支えているのが、GMO独自の考え方である「岩盤ストック収益」です。なくてはならない継続課金型の商材を中心とした、解約率の低いビジネスモデルにより、創業以来右肩上がりの成長を実現。売上高は約3,000億円弱、営業利益は昨年464億円、今年は600億円弱を見込むという、安定したPL構造を参加者にご紹介しました。 その一方で、安定に甘んじることなく、新たな成長領域として注力しているのがセキュリティとAIロボティクス産業です。内田は、AIロボティクスを「産業革命」と位置づけ、AIがビジネスを根本から変え、AIを搭載したロボットが社会で稼働することで、世界は本格的な転換期を迎えるという展望を語りました。 この分野におけるGMOインターネットグループの戦略は、ゴールドラッシュにおける「スコップやジーンズを売る側」に徹すること。AIやロボットそのものを開発するのではなく、AIが動くためのインフラや、ロボットが社会で稼働するためのソリューションを提供することに注力しています。その一例として、莫大な計算資源を必要とするフィジカルAIを支える「GMO GPUクラウド」をご紹介いたしました。 ロボット領域では、2024年6月に設立されたGMO AI&ロボティクス商事株式会社（通称：GMO AIR）を通じ、ロボット普及を担う“商社”としての役割を果たしています。通信、強化学習、セキュリティはロボット運用に不可欠です。インフラに強いGMOインターネットグループがロボティクスに参入することで、大きなシナジーが生まれることが期待されます。なかでも内田はヒューマノイドへの注力を強調し、「2026年はヒューマノイド元年になる」との力強い見通しを示しました。 なお、ヒューマノイドは現在、人材派遣型（レンタル）サービスとして実運用が進められており、日本科学未来館での実証実験をはじめ、イベントや式典、海外カンファレンスなど、さまざまな現場に派遣されています。さらに、セルリアンタワー11階には、世界中のヒューマノイドとロボットエンジニアが集うラボを構想中で、研究・開発・発信の拠点としての展開も予定されています。 「インターネット革命の時代には、ウェブサイトにGMOの商材が組み込まることがひとつの成功例だった。これからは、ロボットの中にGMOの商材が組み込まれる世界がやってくる」。そのためには若い力が必要だ——内田はそう呼びかけ、企業紹介を締め括りました。 人事・エンジニア座談会｜三者三様のキャリア紹介 イベントでは、人事・エンジニア座談会も開催されました。 GMOインターネットグループのブースに登場したのは、ヒューマノイド G1「ひとみん」。 軽快かつ激しいダンスパフォーマンスを披露し、会場の視線を一手に集めました。「現場で動くAI」を体感してたいだける演出は、本イベントの象徴的なハイライトのひとつとなりました。 座談会には、GMOインターネットグループから新卒パートナーの真次、吉田、そしてパネルディスカッションにも登壇していた内野が参加。入社を決めた理由や、AIを前提とした業務環境のリアルなどが率直に語られ、参加者との距離が一気に縮まる時間となりました。 登壇者と学生が近い距離で言葉を交わし、質問が飛び交う様子からは、GMOインターネットグループが大切にしてきた「人」と「挑戦」の文化が自然と伝わってきます。会場は終始熱気に包まれ、大盛況のうちにイベントは幕を閉じました。 後編（協賛レポート3話目）へ、つづく前編（協賛レポート1話目）はこちらから

GMOインターネットグループは、2025年12月21日に行われた学生向けAIキャリアフェス「AIチャレンジャーズフェス2025」にトップスポンサーとして協賛しました。会場となったGMO Yours・フクラスにはAIに熱中する学生150名が集結。基調講演、企業プレゼンテーション、パネルディスカッション、AIキャリアブースと、盛りだくさんのコンテンツをお楽しみいただきました。会場の熱気や各セッションの見どころを中心に、全3回の長編で当日の様子をレポートします。 はじめに　 司会の山田麗奈さん AI人材を目指す学生向けイベント「AI チャレンジャーフェス 2025」が、2025年12月21日に渋谷のGMO Yours・フクラスで開催されました。  AI チャレンジャーズフェス 2025日時：2025年12月21日（日）13:00～19:00場所：GMO yours・フクラス主催：株式会社bestieehttps://ai-fes2025.aishukatsu.com/ 本イベントは、生成AIの急速な普及を背景に、これから社会に出る学生がAI時代に求められる力やキャリアの考え方を掴むことを目的に企画されたものです。当日は、基調講演や企業プレゼンテーション、パネルディスカッションなどを通じて、教育、開発、事業推進といった複数の視点から、学び方や働き方の変化、スキルの磨き方が語られました。  会場提供を含め、GMOインターネットグループは本イベントのトップスポンサーとして参画。PKSHA Technology株式会社、株式会社ディー・エヌ・エー、ソフトバンク株式会社、レバレジーズ株式会社、および Amazon Web Services, Inc.（AWS） といったAI領域の最前線で活躍する企業も集結し、学生に向けてリアルな実務や挑戦の機会が共有されました。 ご挨拶｜GMOインターネットグループ副社長・COO 西山裕之 イベントの冒頭では、GMOインターネットグループを代表して、副社長執行役員・COO／グループ代表補佐の西山 裕之が登壇し、来場者に向けてご挨拶を申し上げました。 西山はまず、本イベントの会場となったGMO Yours・フクラスについて、カフェ兼社員食堂として日常的に開放され、社内外のイベントにも活用されていることをご紹介。毎週金曜日には社員や学生、来訪者が集うバーとして運営され、約1,000人規模が集まる交流の場になっていることにも触れ、GMOインターネットグループが人と人のつながりを重視してきた姿勢を示しました。 続いて、ChatGPTの登場から約3年が経過した現在を起点に、GMOインターネットグループの歩みを振り返ります。GMOインターネットグループは1995年、Windows 95の登場とともにインターネットの商用化が進み始めた時代から事業を展開し、「すべての人にインターネット」という理念のもと、約30年にわたってインターネットのサービスとインフラを支えてきました。現在では、日本国内で約1,800万件の顧客にサービスを提供する規模にまで成長しています。 GMOインターネットグループ副社長・COO 西山裕之 そのうえで西山は、「もしかするとこれまでの時代は、これから始まるAI・ロボティクス時代の前座だったのかもしれない」と語ります。さらに続けて、「AIはインターネット上の情報や社会に存在する多様なデータを取り込み、学習・成長していく存在であり、これからの変化は、人類史上でも最大級の産業革命になる可能性がある」との展望を示します。 これを踏まえて西山は、この大きな転換期を皆様と同時に迎えられたことへの感謝を述べつつ、「この産業革命の時代を、皆さんと共に考え、頭を使い、新しい未来を築いていきたい」と来場者を激励しました。 基調講演｜元デジタル大臣・衆議院議員 河野太郎氏 本イベントの基調講演では、元デジタル大臣であり、行政DXやAI政策を推進してきた衆議院議員・河野太郎氏が登壇。「AI時代を生きる若者と日本の未来」をテーマにスペシャルトークセッションが行われました。司会を務めたのは、本イベントの主催者であり、TBS「東大王」への出演でも知られる株式会社bestiee代表の後藤 弘氏です。 冒頭、河野氏は学生たちを前に「非常に頼もしい面構えだ」と語りかけ、「この日本という国に、これほど力ある若者が育っていることは喜ばしい」と、若い世代への期待を込めました。 セッション前半の問いは、「AI時代に価値を発揮する人材とは」。河野氏は、「AIは破壊的な進化を伴う技術だ」と認めつつ、これからの時代において重要なのは、技術そのものよりも「世界を前提に考える視点」だと強調しました。 「最初から80億人を相手にするのか、それとも1億2,000万人で満足するのか。その差が、結果に大きく表れる」と河野氏は語ります。そのような時代にあって、武器となるのはやはり「英語」。自動翻訳に依存しすぎることなく、日常的な会話や非公式な場面でも「生身でやり取りできる力」を鍛えることの重要性を強調しました。 続く問いは、「日本はAI分野において、今後どのような立ち位置を目指すべきか」。河野氏は、「先ほどの話にも繋がるが、まずは『日本』という枠から飛び出すことだ」と明言し、AIへの投資や研究費が集まる場所へ積極的に出ていくべきだと語りました。「勢いがあるところへ行って、結果を勝ち取ってくる。そのくらいの構えが必要だ」と率直な言葉で、若者が自ら可能性を狭めてしまうことへの警鐘を鳴らします。 さらに、日本のスタートアップが国内市場を起点にしがちな点についても触れ、「日本で成功してからグローバルへ、という発想自体を変えてほしい」と指摘。「『英語ができないので、海外はちょっと』と言っているようでは生き残れない」と、あえて強い言葉で語りました。 元デジタル大臣・衆議院議員 河野太郎氏 自身のキャリアにも触れながら、若いうちに海外で「世界標準」を体験することの重要性を語った河野氏。「若いうちは失敗してもリカバリーできる。だからこそ、20代のうちに世界で自分がどこまで通用するのかを試してほしい」と述べ、挑戦と修正を繰り返すことの価値を強調します。 講演の締めくくりには、学生たちへのメッセージとして、「リスクを恐れずに挑戦してほしい」、そして「困ったときに本当に頼りになるのは、損得のない時代から付き合ってきた友達だ。決して裏切らず、大切にしてほしい」という2点が語られました。 会場に集まった約150名の若者に向け、終始一貫して「日本という枠を越え、世界を前提に考えよ」というメッセージが投げかけられた本基調講演。AI時代を生きるうえでの視座と行動指針を、具体的かつ率直な言葉で示すセッションとなりました。 中編（協賛レポート2話目）へ、つづく

今回、社内向けのアプリケーションを開発するにあたり、上流工程を担当する機会がありました。せっかくなので「試せるところはすべてAIに任せる」といった方針でAIを使ってみました。実務メモとして、使用したプロンプト例と運用のコツを公開します。使用モデルはChatGPT（GPT-5）です。 背景 社内の顧客管理系スタッフツールを新規開発することになりました。スケジュールが厳しめだったこともあり、上流工程に割ける時間が限られている状況でした。「じゃあAIで上流を効率化しよう」と腹をくくり、試行錯誤しながらプロジェクトを進めました。 先に結論（うまくいったこと/難しかったこと） うまくいったこと 画面UIや構成図をSVGで出力し、編集可能なたたき台を高速で作成できたそのSVGを足がかりに、詳細設計のたたきや単体テストケースの初版まで作れたDB設計後の定型チェックを一気に回せた（表記揺れ、型の整合、ルール違反の洗い出し） 難しかったこと スケジュール作成は挫折（プロンプト設計の詰めが甘く、期待通りにならず）DB定義書のゼロから生成は非効率だった（要件伝達のコストが高く、自作の方が速い） 画面UIの叩き台をAIに任せてみた 関係者の合意形成と、開発メンバーとの同期のために画面UIのイメージが必要でした。前提として、今回は社内向けの小規模案件だったため、UIツールで作り込むよりも、納期遵守とスピード優先で「まず形を出す」ことに振り、GPTに依頼してみました。 プロンプト例 一般的な顧客管理用のスタッフツールの画面UIをSVGで生成してください。 構成要素： ・顧客情報、申請情報、お問い合わせ情報が管理されるアプリ ・サイドメニューとメイン画面の構成 ・メイン画面には顧客情報管理画面を表示 ユースケース： 1. 検索条件入力 → 検索実行 → 一覧表示 2. 行クリック → 詳細表示/編集 3. CSVダウンロード、メール送信 ルール： ・すべて日本語ラベル 出力：ダウンロード出来る形でSVGファイルを返すこと。 結果（生成されたSVGファイル） あっという間にこのクオリティの画像が生成されました。UIデザインのスキルがない自分にはこれは参考になります。ありがたい。２度３度と出力させてみても、色々な結果が出てきて勉強にもなります。 そして、このSVGファイルをPowerPointで、挿入＞画像から読み込みます。その後、グループ化解除を選択すると各要素を編集可能となります↓ 必要な要素の追加、不要な要素の削除、微調整などを行って、さくっと画面UIのイメージを作成できました。 実務メモ このフローはアプリケーション構成図にも流用できました。「まず1枚作ってから考える」用途なら、画面遷移図やデータフロー図などにも横展開できそう。実務では、作った画面イメージをGPTに読み込ませて、詳細設計のたたきや単体テストケースの初版まで発展させて生成させました。 DBテーブル定義書の一次レビューを任せてみた 次はDBテーブル定義書です。まずは、ゼロから定義書を作ってもらうのを試しましたが、要件を伝えるのに時間がかかってしまい、効率が悪かったため挫折しました。さらに要件伝達が甘いと、雰囲気のあるものは出るものの、結局全量精査が必要で自分で作った方が速いという結論です。一方で、完成済み定義書の機械チェックは強力でした。今回はExcelで作成した定義書を対象に、下記2工程でのチェックを行いました。(1)同名カラムの型・桁・NOT NULLや命名の揺れを横断比較(2)命名規則・型統一などのルール準拠を点検。 (1)のプロンプト例 添付のテーブル定義書のExcelをレビューしてください。 各テーブルを横断的に比較し、同じカラム名でデータ型・桁数・NOT NULL条件が異なる箇所や、命名の表記揺れがある箇所を洗い出してください。 出力： 問題一覧（テーブル/カラム/問題/根拠/修正案） (1)の結果 （実際の出力のため、テーブル名をマスキングしています）1つ目のチェック。初期のばらつきを一括で潰し、後工程の手戻りを防ぎます。 (2)のプロンプト例 添付のテーブル定義書のExcelをレビューしてください。 各テーブルが下記ルールに沿って定義されているかを確認し、違反している箇所を洗い出してください。 ルール： ・命名規則は小文字＋snake_caseで統一。略語やスペルミスも指摘してください ・主キーは数値のサロゲートキーであること。型はNUMBER(28,0)であること ・時刻型はDATEに統一 ・フラグの型はNUMBER(1)で制約はCHECK (col IN (0,1))、NOT NULL、DEFAULT 0であること 出力： 問題一覧（テーブル/カラム/問題/根拠/修正案） (2)の結果 2つ目のチェック。ルール違反を網羅的に拾ってもらいました。 この2工程で、見落としがちなばらつきを短時間で洗い出せました。 実務メモ 機械的チェックはAI、要件に適合しているかの最終チェックは人の役割として切り分けてレビューしました。定義書の丸投げは難易度が高かったです。ただし「一般的な会員テーブルに必要なカラム列挙」など部分タスクの支援は有効でした。定義書のフォーマットを固定しておけば、同プロンプトで同品質の機械チェックを繰り返し適用できます。 最後のまとめ 「試せるところは全部AI」に振り切ったことの学びとしては、うまく回せば上流工程でAIが生きる場面は多いなと気づけました。上流では、曖昧な要求を形にしていく場面が多いですよね。そこをAIに投げてみると、自分では出せなかったパターンや視点を提案してくれてかなり助けられました。（記事では割愛していますが、細かいタスクもいろいろお願いしています。通信フローの表をまとめてもらったり、ログ出力仕様を一緒に詰めたり、作成したテストの観点漏れを指摘してもらったり。）ただ、結局のところ現場や人によって最適解は違うと思います。今回は社内向けで図の品質基準もゆるめという前提だったので、「AIのたたき台→人の手直し」はハマったなと思っています。一方で、複雑な前提や厳密さが求められる成果物（DB設計や仕様設計など）は、最初から人が手を動かした方が効率的な場面もあると感じました。まずは何でも試して、広げていくのがいいんじゃないかなと。もしどこか一つでも持ち帰ってもらえるポイントがあれば嬉しいです。