姉妹媒体『エンジニアtype』に掲載中の株式会社grasys（グラシス）のインタビュー記事を転載しています。
企業のカルチャーや働く社員のイメージを知るためにご活用ください。
なお、募集職種とは異なる職種やテーマのインタビュー記事が掲載されている可能性もございますので、ご了承ください。
生成AIの進化により、あらゆるエンジニアの職種で「役割の再定義」が急速に進んでいる。その中でも特に劇的な変化の最前線にいるのが、クラウドエンジニアだろう。
自社の膨大なデータを安全にAIと連携させる基盤、AI特有の「不確実性」を制御してシステム全体の崩壊を防ぐアーキテクチャ。AIを「実業務で使える安全なシステム」へと昇華させるクラウド領域の重要性はかつてなく高まっている。
定型的なコードの記述やインフラ構築の一部といった「単なる実装」がAIに代替されつつある今、これからのクラウドエンジニアは現場で何と戦い、どのようなスキルを身につければ生き残ることができるのか。
その答えを探るべく、国内唯一（本記事公開時点）のGoogle Cloudの「生成AIサービス」スペシャライゼーション認定企業である株式会社grasysに着目した。
延べ3億人超のエンドユーザーを支える大規模・高負荷システムの構築実績を持つ同社で、アプリケーション開発の責任者を務める細谷政徳さんに、AI時代に求められるクラウドエンジニアの「真の役割」を聞いた。
株式会社grasys
Cloud Tech Division
Cloud Development Section Leader
細谷政徳さん
SIerでエンジニアとしてキャリアをスタート。その後、ソーシャルゲーム企業にて開発推進グループマネージャーや開発部長を務め、開発組織のマネジメントや大規模サービスの開発に携わる。スタートアップや株式会社meleap、フリーランスとしてゲーム、ARスポーツ、メタバースなどの分野でフルスタック開発を経験。2024年に株式会社grasysへ入社し、Cloud Development Section Leaderとしてクラウド技術を活用したシステム開発やAI関連プロジェクトの開発をリードしている
ーーまずは現場のリアルな変化から伺いたいのですが、生成AIの進化によって、grasysの開発現場では業務内容にどのような影響が出ていますか？
やはり一番は「実装」の領域ですね。当社では、2024年頃からGitHub Copilotなどのコーディング支援ツールを導入していて、定型的なボイラープレートの記述などはAIに任せられるようになりました。おかげで、人間はより複雑なビジネスロジックに集中できています。
後は実装にとどまらず、要件定義やチーム内のコミュニケーションも、AIのサポートのおかげで進め方が変わってきました。
例えば、ミーティングの議事録やドキュメントの要約はもちろんですが、資料用の概念図を画像生成AIにサッと作らせてイメージを共有したり、構成図のベースとなるコードをAIに出力させて素早く可視化したりですね。
ーー実装の手間が減った分、システム設計の観点でエンジニアが「考えるべきこと」は変わってくるのでしょうか？
設計の根本的な考え方自体は変わっていません。ただ、AIが普及したことで「実現できるビジネス要件の幅」が格段に広がりました。
例えば、検索機能一つとっても、以前はRDBMSを中心に文字列ベースで検索することが多かったです。しかし今では、AIとベクトルデータベースを用いた「曖昧検索（意味が近いかどうかでの類似度判定）」が柔軟に実装できます。
今まで技術的なハードルが高くて見送られていたプロダクトのコアな要件が、AIによって直接解決できるケースが多くなったのは大きな変化ですね。
ーーただ、AIは必ずしも「1+1=2」のような決まった答えを返すわけではないですよね。システム全体を設計する上で、その点に難しさはありませんか？
おっしゃる通りで、そこが現在のアーキテクチャ設計の肝になります。
従来のシステムが「確実」だとすれば、生成AIを組み込むシステムは不確実性を前提に設計が必要です。だからこそ、設計においては依存性を下げて拡張性を持たせることが今まで以上に問われます。
例えば、AIの処理結果をそのまま基幹システムの更新に直結させるのは注意が必要です。AI側の遅延や障害を業務処理に影響させないために、Cloud RunやPub/Subを使って非同期に切り分けておく必要があります。さらに、出力の揺らぎや想定外の結果に備えて、検証や承認のステップを挟める構成にしておくことも重要です。
万が一、AI側で問題が起きたり、想定外の挙動をしたりしても、他システムに影響が出ないアーキテクチャを組む力が、これからのクラウドエンジニアには必須になります。
ーーシステム全体への影響を防ぐ設計の重要性は分かりました。とはいえ、AIの出力自体が「業務で使えるレベルか」を見極める必要もありますよね。
はい。だからこそ、私たちはアーキテクチャ設計と、AIの出力を評価・レビューする工程に最も時間を割いています。特にエンタープライズの業務で使う上では、先ほど話に出たような「AIの不確実性」をどう評価するかが非常に重要になるんです。
ーー具体的にはどのように評価するのでしょうか？ テストコードによる自動判定などは難しそうです。
例えば、社内ドキュメントの検索基盤（RAG）を構築したとします。AIは「それっぽい回答」を返しますが、現場の人間から見ると「いや、こっちのドキュメントの方が今の業務の文脈に合っているのに、なぜ上位に来ないんだ？」という感覚的なズレが必ず生じます。
定量的な評価であれば自動化は可能ですが、こうした定性的な評価はシステムでの判定が難しく、安定するまでに時間がかかるケースが多くあります。だからこそ、AIを運用する上で重要になるのが「Human-in-the-loop（人間の介入）」です。
評価サイクルの一例としては、ユーザー側に「Good / Bad」ボタンを設置してフィードバックを集め、Badが押されたら管理者のダッシュボードに一覧表示されるようにします。
管理者はそれを確認し、ハルシネーションを防ぐための「根拠付け」の調整を行い、再度リリースする。こうしたサイクルを回すようなこともあります。
ーー作って終わりではなく、人間が介入して精度を上げていく運用がセットなんですね。
はい。当社では過去に島津製作所様のAI検索基盤の構築をお手伝いしたことがあるのですが、実際の現場では運用しながら一つ一つ調整を重ねていく場面が少なくありません。
例えば、「産廃」のような業界用語をAIが正しく認識してくれなかったり、図面のOCR読み取りで「φ（ファイ）」という記号を数字の「4」と誤認してしまったり。そうした現場特有の課題に対して、検索モデルに業界用語のコーパス（※）を追加してチューニングしたり、複数のAPIを組み合わせて誤認を防いだりと、エンジニアが一つ一つ対策を打って精度を上げていきました。
AIに権限を委譲して業務を行わせる以上、もし業務上問題のある挙動を起こした時に「AIが作ったものなので関係ありません」では済みません。だからこそ、チームとして評価と運用の仕組みまでしっかり考える必要があります。
その上で、こうした評価とチューニングのサイクルに加えて、システムを支える「非機能要件」まできちんと設計することが重要ですね。
例えば、APIのコール数が増大した際のコストコントロールや、推論速度の遅延を許容するためのUX設計など、従来のインフラ設計とは異なるAI特有の非機能要件をどう定義するかが、エンジニアの腕の見せ所になります。
（※）コーパス｜新聞、書籍、会話などの自然言語（人間が使う言葉）のデータを、コンピュータで分析・検索可能な形式で大規模に収集・構造化した言語データベースのこと
ーーそうした高度なインフラ基盤を構築する上では、クラウド選びも重要になります。grasysが得意としている「Google Cloud」の優位性はどこにあると感じますか？
AIとデータ活用を前提にすると、Google Cloudはかなり相性の良いプラットフォームだと思います。
他社クラウドと比較して、AI検索やデータ活用のためのサービスがそろっていて、PoCから実運用までつなげやすい点に強みを感じます。また、Gemini Enterpriseのようにノーコードでワークフローを自動化できるポテンシャルの高さも魅力です。
ただ、これからのエンジニアの市場価値を考えた時に最大の強みとなるのは、AIそのものよりも「データ基盤」の方ですね。
ーーAIモデルそのものではなく、データ基盤ですか？
優秀なAIモデル自体は今後どんどんコモディティ化していきますし、誰もが使えるようになります。エンタープライズで最後に勝負を分けるのは、自社独自のクリーンなデータをどれだけ持っていて、それをAIに活用できるかです。
実際、現場で「AIを活用したい」というオーダーを受けてRAGを組んでみると、社内ドキュメントのフォーマットがバラバラだったり、何年も前の古い仕様書と最新情報が混在していたり……。こうした現実的な課題と直面することが多いんです。
その状態でいくら優秀なAIに読み込ませても、文脈の破綻したものしか出力されず、使い物になりません。
AI活用を進めようとすると、最終的にはデータをどう整備し、どう更新し、どうつなぐかが大きなテーマになります。だからこそ、データパイプラインやデータ基盤への需要は今後ますます高まると感じています。
その点において、Google Cloudのデータウエアハウスである「BigQuery」の圧倒的なスケーラビリティーは大きな武器になります。BigQuery上のデータ活用と機械学習基盤の連携がしやすく、分析からAI活用までの流れを設計しやすい点は強みです。
ただデータを溜めるだけでなく、「AIで活用しやすい形に整えるためのデータクレンジングと連携」をシームレスに行えるのは、現場のエンジニアにとって他にはない強力なアドバンテージですね。
ーークラウドエンジニアに求められる役割やスキルを伺ってきましたが、今後それらのスキルを身に付けたい若手エンジニアにとって、AIは強力な学習支援ツールになりますよね。
そうですね。ただ、これは若手に限らず中堅以上のエンジニアでも陥りがちな罠があると感じています。
AIを使えば「それっぽく動く成果物」は誰でも簡単に作れてしまいます。しかし、AIが生成したものを理解しないままAIのコードを鵜呑みにすると、いざ本番環境で複雑なバグやパフォーマンスの劣化に直面した時に「どこがボトルネックか」を切り分けるトラブルシューティングが難しくなります。
便利な時代だからこそ、ブラックボックスをそのままにせず、「なぜこのアーキテクチャで動くのか」「どういう挙動なのか」を自分の手で試しながら確かめることが大切です。ドキュメントを読むだけでは得られない理解を積み重ねることが、エンジニアにとっての基礎力になると思います。
ーーAIに答えを出させるのではなく、あくまで補助として使うと。
AIに自分の代わりとして成果物を作らせること自体が問題なのではなく、その結果を自分で評価できないまま業務に使うことが危険だと思っています。だからこそ、まずは自分で妥当性を判断できる範囲で活用することが大切です。
私のキャリアの根底にあるポリシーは「常に期待の1.5倍を超えること」です。ただ、仕様書通りにきちんと動くものを作るだけでも、実は簡単なことではありません。
まずはそこを確実にやり切った上で、さらに性能や運用性、将来の拡張性まで踏み込んで工夫する。そうした積み重ねが、結果として期待を超えるアウトプットにつながると思っています。
裏側の設計がモダンか、パフォーマンスは極限まで出ているか。そういった非機能要件にこだわり、「ここからさらに良くできないか」を深く追求する姿勢こそが、これからの時代も価値を出し続けるエンジニアのベースになります。そして、そこにおもしろさがあります。
ーーそうした基礎力を固めつつ、AIなどの最新技術にも触れ続けるためには、どのような環境に身を置くのが理想だとお考えですか？
やはり、「技術的に挑戦できる幅の広さ」と「刺激をもらえるカルチャー」の両方がある環境ですね。
例えば私の管轄するCloud Development Sectionには、4人体制のチームが二つあるのですが、AI検索基盤の構築から、BigQueryを用いたデータパイプライン、基幹システム開発など、クラウドインフラからバックエンド、フロントエンド開発まで非常に幅広い領域を扱っています。
当社は代表の長谷川（祐介）をはじめ、純粋に技術が好きで最新情報を常に追っているメンバーが多いんです。Google Cloudの「生成AIサービス」スペシャライゼーション認定企業として最前線のAIプロジェクトに関わりながら、日常的に「このアーキテクチャをもっと良くできないか」と議論できる環境があります。
もちろん、生成AIの進化は凄まじいので、そのスピードに遅れを取らないよう、常に最新情報をキャッチアップし続ける技術集団でありたいです。
ただAIをツールとして使うだけでなく、「このビジネス課題は、このAI機能と自社のデータ基盤を掛け合わせれば解決できる」というアーキテクチャの視点を提案し続ける。私たちが掲げる「攻めの開発」を、AI時代に合わせた形でさらに体現していきたいですね。
撮影／赤松洋太 取材・文／今中康達（編集部）
