こんにちは。アマゾン ウェブ サービス ジャパン合同会社 パートナー ソリューション アーキテクト の深井宣之です。 2026 年 4 月 28 日に「公共分野における AI 活用最新アップデート」と題した Webinar を開催しました。本ブログでは開催内容について Blog にまとめたものになります。投影資料もダウンロードすることが可能です。 本セッションでは、アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 CSM・プロトタイプ・パートナー ソリューション技術本部 本部長の高田 智己が登壇し、生成 AI の最新トレンドとして「チャットボット + RAG」の時代から「Agentic AI」の時代への移行を解説しました。AWS が提供する AI サービスの全体像を紹介したうえで、中央省庁・地方自治体・ヘルスケア・大学など公共分野における生成 AI 活用の最新ユースケースを多数紹介しました。 セッション概要 資料（PDF）の ダウンロードはこちら から可能です。 生成 AI の最新トレンド ― Agentic AI 時代へ 2022 年末に ChatGPT が登場して以降、生成 AI や RAG（検索拡張生成）が注目を集めてきました。しかし 2025 年 3 月頃からは「AI 駆動開発」「MCP（AI と既存システム連携）」「AI エージェント」といったキーワードが中心となり、AI エージェントが気軽に使える状況が整ってきています。 生成 AI はシンプルなコンテンツ生成を行う「アシスタント」から、単一ゴールを自律的に達成する「生成 AI エージェント」、そしてワークフロー全体を完全自動化する「Agentic AI システム」へと進化しています。Amazon 自身も Alexa+ や代理購買サービス「Buy For Me」など、多くのプロダクトで AI エージェントを活用しています。 AWS の提供する生成 AI サービス AWS では 3 層の AI サービスポートフォリオを用意しています。 AI モデルを作りたい方向け : AWS Trainium / Inferentia によるカスタムチップ、Amazon SageMaker HyperPod などのインフラストラクチャ AI エージェントを作りたい方向け : Amazon Bedrock（基盤モデルへの API アクセス）、Amazon Bedrock Agents、Amazon Bedrock AgentCore、Strands Agents などのフレームワーク すぐに使える AI エージェント : Kiro（AI 統合開発環境）、Amazon Quick Suite、AWS Transform、Amazon Connect など Amazon Bedrock Amazon Bedrock は東京リージョンを含む複数のリージョンで一般提供されている、基盤モデルを活用した生成 AI アプリケーションの構築サービスです。Anthropic の Claude シリーズをはじめ幅広いモデルを利用でき、データプライバシーの観点ではお客様のデータが他のお客様のために使用されることはなく、日本国内クロスリージョン推論もサポートされています。 Amazon Bedrock AgentCore AI エージェントの大規模かつ安全なデプロイ・運用を実現するプラットフォームです。認証・認可（Identity）、ツール管理（Gateway）、実行環境（Browser / Code Interpreter）、セッション記憶管理（Memory）、運用監視（Observability）などの機能を提供し、お客様は AI エージェントのコア開発に集中できます。 AI コーディングエージェント AWS が提供する AI コーディングエージェントとして、生成 AI 統合開発環境の Kiro と、Anthropic 社の Claude Code を Amazon Bedrock 上で利用する方法を紹介しました。Kiro では仕様駆動開発によりプロトタイプからプロダクションまでを支援し、レガシーアプリケーション（Delphi/Pascal）の解析とモダン化にも活用できることをデモで示しました。 公共分野における生成 AI 活用の最新ユースケース 本セッションの後半では、公共分野における生成 AI 活用の最新ユースケースとして、以下の事例が紹介されました。 事例 1: デジタル庁 ― ガバメント AI「源内」 デジタル庁では、政府職員の業務効率化のために生成 AI 検証アプリ「源内（ゲンナイ）」を AWS 上に構築しました。GenU（Generative AI Use Cases）をベースに開発されており、機密性 2 情報の利用が可能です。2025 年 5 月にデジタル庁職員向けにリリースされ、2026 年 1 月から一部省庁で試験的利用を開始。2026 年度には全府省庁約 18 万人の政府職員が生成 AI を活用する大規模実証事業が予定されています。 なお、源内のベースとなっている GenU は AWS Japan の有志チームが開発したオープンソースの生成 AI アプリケーションで、チャット・翻訳・文書校正・要約など業務で活用できるユースケースを提供しており、1,000 を超えるお客様での利用実績があります。 事例 2: 国土交通省 ― AI 書類審査ソリューション「RAPID」 2025 年 4 月の改正建築基準法施行により 2 階建て木造住宅等も審査対象に追加され、審査機関の業務負荷が急増しました。国土交通省では、AWS プロトタイプチームが開発したオープンソースの AI 書類審査ソリューション「RAPID（Review & Assessment Powered by Intelligent Documentation）」を活用し、日本建築防災協会が提供する「建築確認申請図書作成支援サービス」を開発。OSS の活用により開発 2 か月でサービスをリリースし、申請補正指示案件の削減による審査業務負荷軽減が期待されています。 事例 3: つくば市 ― 相談業務効率化 つくば市では、ひとり親支援担当部署において相談記録のテキスト量が多く、転出時の要約資料作成に苦労していました。この課題に対し、GenU をベースにしたソリューションをガバメントクラウド上に構築し、生成 AI による相談記録の要約を実現。大量のケース記録から簡潔な要約を自動生成することで、転入先自治体への情報共有やケース会議での検討を効率化しています。 事例 4: 品川区 ― AI エージェントを活用した問合せ対応自動化 品川区では、人口増加に伴う住民ニーズの多様化や全国的な労働力不足、電話対応業務の負荷増大に課題を抱えていました。Amazon Connect と Amazon Bedrock を活用した AI 自動応答システムの実証実験を実施し、FAQ への自動応答、適切な部署へのルーティング、24 時間対応、必要に応じたオペレーターへのエスカレーションを実現。待ち時間短縮と住民満足度向上、職員の業務負荷軽減、持続可能な行政運営の実現を目指しています。 事例 5: 藤田医科大学 ― 退院時サマリー作成補助 藤田医科大学では、医師や医療従事者が業務時間の多くを文書作成に費やしており、退院時サマリー作成には 1 患者あたり 10〜15 分を要していました。Amazon Bedrock を活用したプロトタイピングプログラムにより、電子カルテ記事を元にサマリー生成の精度を 1 か月で検証。医師作成のサマリーに対し 9 割以上で整合性が取れることを確認し、10 分程度の作成作業が数秒で下書き完成に短縮されました。現在は 31 診療科に展開されています。 事例 6: ソフトウェア・サービス ― 電子カルテシステムへの生成 AI 活用 株式会社ソフトウェア・サービスでは、医師の 52.9% が週 60 時間超勤務、看護師の 7 割が時間外勤務という医療現場の深刻な業務負担に着目し、Amazon Bedrock を活用して電子カルテシステムに生成 AI を連携させました。その結果、サマリー作成時間 50% 削減、心理的負担 70% 低下を実現しています。 事例 7: 東北大学 ― 教職員向け生成 AI アプリ 東北大学では、2020 年に DX 推進チームを発足し、全国の大学に先駆けて生成 AI を導入してきました。GenU をカスタマイズし、チャット・文書作成・議事録作成などの AI ユースケースを全教職員向けに提供しています。検討から 1 か月で内製構築しサービスを開始。会議議事録作成時間が 1/4 に短縮され、ランニングコストも従来の 1/3 に抑えられています。 事例 8: 東京科学大学 ― 日本語大規模言語モデル Swallow の開発 東京科学大学（東京医科歯科大学と東京工業大学が 2024 年 10 月に統合）では、年度末までに大規模言語モデルの継続事前学習を完了させる必要があり、大規模並列の学習用計算環境が求められていました。Amazon SageMaker HyperPod を用いて ml.p5.48xlarge / ml.p5en.48xlarge の学習環境を数時間で構築し、FSx for Lustre と S3 を連携。GPT-4o に匹敵する高性能な日本語大規模言語モデル「Swallow」最新版（Llama-3.3-Swallow-70B 等）のリリースに貢献しました。 おわりに AWS では AI モデルを作りたいお客様へのインフラ提供から、AI エージェントを作りたいお客様へのサービス・フレームワーク提供、そしてすぐに AI エージェントを使いたいお客様向けのサービスまで、多くの選択肢を提供しています。デジタル庁の源内をはじめ、国土交通省、つくば市、品川区、藤田医科大学、東北大学、東京科学大学など、公共分野でも幅広く AWS の生成 AI サービスが活用されています。 本セッションでご紹介した AWS のサービスやソリューションにご興味がありましたら、御社担当の Partner Account Manager にお気軽にご連絡ください。 このブログは、アマゾン ウェブ サービス ジャパン合同会社 パートナー ソリューション アーキテクト 深井宣之が執筆しました。

本記事は 2025 年 9 月 22 日 に公開された「 A scalable, elastic database and search solution for 1B+ vectors built on LanceDB and Amazon S3 」を翻訳したものです。 この記事は Metagenomi の Owen Janson、Audra Devoto、Christopher Brown との共著です。 CRISPR によるゲノム編集から産業用バイオ触媒まで、酵素はヘルスケア、エネルギー、製造業における変革的な技術を支えています。しかし、ゲノム工学における Cas9 のように産業を変えるような新規酵素を発見するには、生命の系統樹にまたがる膨大な生物がコードする数十億種類の酵素を探索しなければなりません。DNA シーケンシングとメタゲノミクスの進歩により既知のタンパク質配列を格納した大規模な公開・独自データベースが構築されてきましたが、そこから価値の高い候補を見つけ出すのは生物学の問題であると同時にビッグデータの問題でもあります。 Metagenomi では、独自の大規模メタゲノミクスデータベース (MGXdb) を活用し、新規遺伝子編集システムのツールボックスを構築することで、根治的な治療法の開発に取り組んでいます。この記事では、Metagenomi が Amazon Web Services (AWS) のスケーラブルなインフラを使い、エンベディングに基づく高性能タンパク質データベースと検索ソリューションを構築して、数十億タンパク質規模の酵素発見に挑んでいる方法を紹介します。独自の大規模データベースに含まれるすべてのタンパク質をベクトル空間にエンベディングし、 Amazon Simple Storage Service (Amazon S3) 上に構築した LanceDB でデータにアクセスできるようにして、 AWS Lambda で検索することで、酵素発見を最近傍探索問題に変換し、これまで未探索だった発見空間に高速にアクセスできるようになりました。 ソリューション概要 このソリューションの中心にあるのが LanceDB です。LanceDB はオープンソースのベクトルデータベースで、インデックス付きベクトルに対する高速な近似最近傍 (ANN) 検索を実現します。LanceDB は完全にファイルベースで Amazon S3 ストレージとも互換性があるため、サーバーレス構成に適しています。その結果、エンベディング済みタンパク質配列のデータベースを Amazon Elastic Block Store (Amazon EBS) のような永続ディスクではなく、比較的低コストな Amazon S3 に保存できます。常時稼働するサーバーは不要で、データベースをオンデマンドで検索するのに必要なのは、LanceDB を使って S3 上のデータから直接最近傍を見つける Lambda 関数だけです。 Metagenomi の大規模タンパク質データベースを表す数十億のベクトルエンベディングを取り込み・検索するために、データベースを均等なサイズのパーツ (フォルダ) に分割して Amazon S3 に低コストで保存し、それらを並列にインデックス化して Lambda による map-reduce アプローチで検索する方法を考案しました。以下の図がこのアーキテクチャを示しています。 処理は 4 つのステップで構成されています。 データのベクトル化 データのバケット分割 データの取り込みとインデックス作成 データベースへのクエリ データのベクトル化 LanceDB の高速な ANN 検索機能を利用するには、データをベクトル形式にする必要があります。Metagenomi のメタゲノミクスデータベースには数十億のタンパク質が含まれており、それぞれがアミノ酸の文字列です。各タンパク質を生物学的に意味のある情報を捉えたベクトルに変換するため、タンパク質言語モデル (pLM) に通し、モデルの隠れ層をそのタンパク質のベクトル表現として取得します。タンパク質エンベディングの生成にはさまざまな pLM が使用でき、求める生物学的情報と計算要件に応じて選択します。今回は AMPLIFY_350M モデル を使用しました。データベース全体へのスケーリングに十分な速度を持つ Transformer エンコーダモデルです。モデルの最終隠れ層に対して mean-pool を実行し、各タンパク質について 960 次元のベクトルを生成します。生成されたベクトルと対応する一意のタンパク質 ID は HDF5 ファイルに保存します。 データのバケット分割 タンパク質ベクトルを検索可能なデータベースにするために、LanceDB でクエリの ANN を高速に見つけるためのインデックスを構築します。しかしインデックス作成には時間がかかり、複数ノードへの分散も困難です。インデックス作成を高速化するため、まずデータをほぼ均等なサイズのバケットに分割します。エンベディング HDF5 ファイルを best-fit bin packing アルゴリズムで合計約 2 億ベクトルのバケットに割り当てます。バケット分割に使う具体的なサイズ決定方法は、ベクトルの数、次元数、フォーマットによって異なります。各バケットは Amazon S3 上の単一の LanceDB データベースオブジェクトストア内に独立したテーブルとして取り込まれます。 データをバケット分割することで、個別ノードで並列にインデックス化できる小さなデータベースを複数作成でき、インデックス作成時間を大幅に短縮できます。また、既存データ全体を再インデックスする代わりに、新しいバケットとしてデータを追加でき増分追加も容易です。 バケット分割データの取り込みとインデックス作成 ベクトル化されたデータがバケットに割り当てられたら、LanceDB テーブルに変換してインデックスを作成し、高速な ANN クエリを可能にします。データを LanceDB テーブルに変換する具体的な方法は LanceDB のドキュメント を参照してください。約 2 億ベクトルの各バケットに対して、コサイン距離の IVF-PQ インデックスを持つ LanceDB テーブルを作成します。インデックス作成では、パーティション数は挿入行数の平方根、サブベクトル数はベクトル次元数を 16 で割った値を使用します。 クエリをスムーズにするため、各テーブルは作成元のバケットにちなんだ名前を付け、単一の S3 ディレクトリにアップロードします。ファイル構造から見ると、複数テーブルを持つ 1 つの LanceDB データベースとして認識されます。 以下のコードスニペットは、 id カラムと embedding カラムを含む HDF5 ファイルからベクトルを LanceDB データベースに取り込み、コサイン距離による高速 ANN 検索用にインデックスを作成する例です。実行に必要なのは python >= 3.9 と lancedb 、 pyarrow 、 h5py パッケージです。このスニペットは非同期 LanceDB API を使用する lancedb バージョン 0.21.1 でテスト・開発されています。 from typing import List, Iterable from itertools import islice from math import sqrt import pyarrow as pa import datetime import asyncio import lancedb import h5py def batched(iterable: Iterable, n: int) -> Iterable[List]: """Yield batches of n items from iterable.""" while batch := list(islice(iterable, n)): yield batch async def vectors_to_db( vectors: str, db: str, table_name: str, vector_dim: int, ingestion_batch_size: int, ) -> int: """Ingest and index vectors from an HDF5 file into a LanceDB table. Args: vectors (str): An HDF5 file containing protein IDs and their 960-dimension vector representations. db (str): Path to the LanceDB database. table_name (str): Name of the table to create. vector_dim (int): Dimension of the vectors. """ # create db and table custom_schema = pa.schema( [ pa.field("embedding", pa.list_(pa.float32(), vector_dim)), pa.field("id", pa.string()), ] ) # count the total number of rows as they are added to the table total_rows = 0 # open a connection to the new database and create a table with await lancedb.connect_async(db) as db_connection: with await db_connection.create_table( table_name, schema=custom_schema ) as table_connection: # open vectors file with h5py.File(vectors, "r") as vectors_handle: # create a generator over the rows rows = ( {"embedding": e, "id": i} for e, i in zip( vectors_handle["embedding"], vectors_handle["id"], ) ) # insert rows in batches to avoid memory issues for batch in batched(rows, ingestion_batch_size): total_rows += len(batch) await table_connection.add(batch) # optimize the table and remove old data await table_connection.optimize( cleanup_older_than=datetime.timedelta(days=0) ) # configure the index for the table index_config = lancedb.index.IvfPq( distance_type="cosine", num_partitions=int(sqrt(total_rows)), num_sub_vectors=int( vector_dim / 16 ), ) # index the table await table_connection.create_index( "embedding", config=index_config ) # ingest and index your data asyncio.run( vectors_to_db( vectors="./my_vectors.h5", db="./test_db", table_name="bucket1", vector_dim=960, ingestion_batch_size=50000 ) ) ベクトル化、取り込み、各バケットのインデックス作成は、複数の AWS Batch ジョブで並列実行することも、単一の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行することもできます。 データベースへのクエリ データがバケット分割され Amazon S3 上の LanceDB データベースに取り込まれたら、クエリの手段が必要です。LanceDB は LanceDB Python API を使って Amazon S3 から直接クエリできるため、Lambda 関数でユーザーが指定したクエリベクトルを受け取り、ANN を検索して結果を返すことができます。ただし、データが複数テーブルにバケット分割されているため、各バケットで最近傍を検索し、結果を集約してからユーザーに返す必要があります。 クエリワークフローは AWS Step Functions の ステートマシン として実装しています。各バケットに対するクエリ処理を Lambda プロセスとして管理し、最後に単一の Lambda プロセスがデータを集約して結果の ANN を .csv ファイルとして Amazon S3 に書き込みます。AWS Batch プロセスやローカル実行でも代替可能です。以下のスニペットは、1 つのバケットに対して ANN クエリを実行するプロセスの例です。実行に必要なのは python >= 3.9 と pandas 、 lancedb パッケージです。取り込みセクションと同様に、非同期 LanceDB API と lancedb バージョン 0.21.1 を使用しています。 from typing import List, Iterable import asyncio import lancedb import pandas import random async def run_query_async( lancedb_s3_uri: str, table_name: str, q_vec: List[float], k: int, vec_col: str, n_probes: int, refine_factor: int, ) -> pandas.DataFrame: """Run a query on a LanceDB table. Args: lancedb_s3_uri (str): S3 URI of the LanceDB database. table_name (str): Name of the table to query. q_vec (List[float]): Query vector. k (int): Number of nearest neighbors to return. vec_col (str): Column name of the vector column. n_probes (int): Number of probes to use for the query. refine_factor (int): Refine factor for the query. Returns: pandas.DataFrame: DataFrame containing the approximate nearest neighbors to the query vector. """ # open a connection to the database and table with await lancedb.connect_async( lancedb_s3_uri, storage_options={"timeout": "120s"} ) as db_connection: with await db_connection.open_table(table_name) as table_connection: # query the approximate nearest neighbors to the query vector df = ( await table_connection.query() .nearest_to(q_vec) .column(vec_col) .nprobes(n_probes) .refine_factor(refine_factor) .limit(k) .distance_type("cosine") .to_pandas() ) return df # query the example bucket we produced in the last section bucket1_df = asyncio.run( snippets.run_query_async( lancedb_s3_uri="s3://mg-analysis/owen/20250415_lancedb_snippet_testing/test_db/", table_name="bucket1", q_vec=[random.random() for _ in range(960)], k=3, vec_col="embedding", n_probes=1, refine_factor=1, ) ) 上記のクエリは以下の構造を持つ pandas DataFrame を返します。 embedding id _distance [-5.124435, 4.242000, …] id_1 0.000000 [-5.783999, 4.340500, …] id_2 0.001000 [-6.932943, 3.394850, …] id_3 0.04020 embedding カラムには最近傍のベクトル表現、 id カラムにはその ID、 _distance カラムにはクエリベクトルとのコサイン距離が格納されています。 各バケットが個別のノードで検索され、それぞれが最近傍の DataFrame を返した後、結果をマージしてユーザーに返す必要があります。以下のスニペットはその方法の例です。 def aggregate_nearest_neighbors( dfs: List[pandas.DataFrame], k: int ): """Aggregate the nearest neighbors for each query vector. Args: dfs (List[pandas.DataFrame]): A list of DataFrames containing the nearest neighbors queried from each bucket. k (int): The number of nearest neighbors to aggregate. Returns: pd.DataFrame: A DataFrame with the aggregated nearest neighbors. """ # concatenate the DataFrames and get the top k nearest neighbors return ( pandas.concat(dfs, ignore_index=True) .sort_values(by=["_distance"], ascending=True) .reset_index(drop=True) .head(k) ) # add the dataframes from querying each bucket to a list dfs = [bucket1_df, bucket2_df, bucket3_df, bucket4_df, bucket_5] # aggregate the nearest neighbors across all buckets nearest_neighbors_all_buckets_df = aggregate_nearest_neighbors(dfs, 5) 大量クエリの最適化 Lambda で S3 上の LanceDB データベースを直接検索する方法は、1 つまたは少数のクエリベクトルの ANN 検索には適していますが、数千から数百万のベクトルをクエリする必要があるユースケースもあります。 大量クエリに対してスケールする方法として、先述のクエリ実装を変更し、まずデータベースのバケットの 1 つをローカルストレージにダウンロードしてから LanceDB API でローカルに検索する方式を採用しています。データベースバケットのストレージサイズが大きいため、この実装は Lambda よりも AWS Batch ジョブに適しており、EBS ボリュームではなく最適化されたインスタンスストレージ (例: i4i インスタンス) の使用を推奨します。すべてのクエリ Batch ジョブが完了した後、最終ジョブが結果を集約してからユーザーに返します。並列クエリジョブと集約ジョブのオーケストレーションには Nextflow が使用できます。バケットをディスクにダウンロードするオーバーヘッドとレイテンシーは増加しますが、大量のクエリをより効率的に処理でき、常時稼働のサーバーベースデータベースも不要です。 ベンチマーク結果 インデックス戦略やデータベース分割サイズは、求めるパフォーマンスに依存します。ユースケースに合わせてカスタマイズする際の一般的な最適化ガイダンスを以下に示します。 Metagenomi が作成したデータベースの例では、AMPLIFY で生成した 960 次元のベクトルエンベディング 35 億件を格納しています。この 35 億ベクトルエンベディングを 2 億ベクトルごとに分割し、 i4i.8xlarge インスタンスで取り込みとインデックス作成を行ったところ、合計 108 コンピュート時間で完了しました。このソリューションはサーバーレスで S3 オブジェクトストアから直接クエリできるため、データベースの固定コストは Amazon S3 上のストレージ容量のみです (35 億ベクトルのインデックス済みデータベースで約 12.9 TB)。Lambda によるクエリは非常に低コストで、多くのクエリが 1 セント未満で実行できます。 一般的に、分割サイズが大きいほどクエリのコスト効率は高くなりますが、実行時間とインデックス作成時間は長くなります。単一分割で許容可能なクエリ応答時間を維持できる最大サイズまでスケールアップし、同時に Lambda 同時実行数の上限などの並列化の制約も考慮することを推奨します。Metagenomi では 2 億ベクトルごとの分割が、小規模・大規模両方のクエリでコストと実行時間の最適なバランスを示しました。取り込みとインデックス作成には i4i ファミリーなどのストレージ最適化インスタンスの使用を推奨します。ディスクベースのデータベースでクエリを実行する場合 (Lambda + Amazon S3 ではなく) も、ストレージ最適化インスタンスの使用を推奨します。Lambda 実装では、最大 50,000 ANN を要求する単一クエリ、または 5 ANN 未満で最大 100 シーケンスのマルチクエリを素早く処理できました。以下のグラフに示すように、実行時間は要求する ANN 数に対して線形に増加します。 まとめ この記事では、Metagenomi が LanceDB を Amazon S3 と AWS Lambda 上に実装し、数十億のタンパク質エンベディングを低コストで保存・検索する方法を紹介しました。この取り組みは、Metagenomi が根治的な遺伝子治療の開発に向けて推進する、新規酵素の発見とエンジニアリングプラットフォームの加速に貢献しています。クエリタンパク質の ANN エンベディング空間に数秒でアクセスできるようになったことで、大規模な解析パイプラインに高速検索手法を統合し、多様で新規な酵素ファミリーの発見を加速し、研究者がエンベディングをオンザフライで生成・検索する手段を提供してタンパク質エンジニアリングの取り組みを可能にしています。Metagenomi がタンパク質・DNA データベースの急速な拡大を続ける中、並列にインデックス化・検索できるデータベース分割による水平スケーリングが、将来のニーズに対応するエンベディングデータベースソリューションを実現しています。 この記事で紹介したソリューションはタンパク質 大規模言語モデル (LLM) で生成したベクトルに焦点を当てていますが、他のベクトル化されたデータセットにも適用できます。Amazon S3 と統合した LanceDB の詳細は LanceDB のドキュメント を参照してください。 参考文献 Fournier, Quentin, et al. “Protein language models: is scaling necessary?.” bioRxiv (2024): 2024-09. 著者について Audra Devoto Audra はメタゲノミクスのバックグラウンドを持つデータサイエンティストで、AWS 上の大規模ゲノミクスデータセットの取り扱いに長年の経験があります。Metagenomi では大規模解析プロジェクトを支えるインフラを構築し、MGXdb からの新規酵素発見を推進しています。 Christopher Brown Christopher Brown 博士は Metagenomi の Discovery チーム責任者です。メタゲノミクスの専門家であり、遺伝子編集応用に向けた多数の新規酵素システムの発見と特性解析を主導してきました。 Patrick O’Connor Patrick は AWS のシニア WorldWide AI プロトタイピングエンジニアで、クラウド上で生成 AI ソリューションとエンドツーエンドのプロトタイプを構築しています。大規模言語モデルと分散 AI システムの実装を専門としており、IoT、サーバーレス技術、ハイパフォーマンスコンピューティングの知見を活かして企業の複雑な課題解決に取り組んでいます。 Owen Janson Owen は Metagenomi のバイオインフォマティクスエンジニアで、大規模ゲノミクスデータセットの解析を支えるツールとクラウドインフラの構築に注力しています。 Pavel Novichkov Pavel Novichkov 博士は AWS のシニアソリューションアーキテクトで、ゲノミクスとライフサイエンスを専門としています。15 年以上のバイオインフォマティクスとクラウド開発の経験を持ち、ヘルスケア・ライフサイエンス分野のスタートアップが AWS 上でクラウドベースのソリューションを設計・実装する支援を行っています。NIH の National Center for Biotechnology Information でポスドク研究を行い、Berkeley Lab で 12 年以上計算研究科学者として勤務しました。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

  はじめに こんにちは。Insight Edge(以下IE)でセールスコンサルタントをしている石高です。 この記事では、Insight Edgeが住友商事における生成AI活用促進支援の一環として実施したバイブコーディング研修(生成AI研修)についてご紹介します。 Insight Edgeは技術集団としてこれまで住友商事グループ企業に対して幅広いデジタルソリューションの提供を行ってきましたが、IEの支援領域は技術提供・導入にとどまらず、デザインストラテジストやワークショップデザイナーをはじめとする専門性を持ったメンバーを中心に、戦略策定や文化醸成施策の検討、ビジネス課題の解決支援などにも携わってきています。 本研修は2025年度に住友商事のあるグループ（以下、「当該グループ」）を対象に開催され、研修内容の設計および実施をInsight Edgeが担当しています。   生成AI x 業務効率化を目指す研修設計 研修全体像 Why バイブコーディング？ 研修の成果 まとめ     生成AI x 業務効率化を目指す研修設計 住友商事では既に全社横断でCopilotをはじめとした生成AIツールが積極的に利用されており、それに伴う社内研修やワーキンググループの活動が活発に行われているだけではなく、中期経営計画の重要方針「デジタルで磨き、デジタルで稼ぐ」を具現化するための全社戦略「Digital and AI Strategy (DAIS)」が推進されています。 https://www.irwebcasting.com/20260527/4/b134e14786/mov/main/index.html こうした環境の下、当該グループとの企画設計の結果、本研修では、生成AIリテラシーの底上げ及び、生成AI活用による業務効率化を目的に据えました。具体的には、業務での生成AI活用のイメージを持てるようになることや、自身の業務改善を題材に具体的な検討を行い、生成AIを活用して、業務効率化・改善を経験すること等です。 目的実現のため、本研修を通じて参加者が身に付けるべきスキルは以下2点であると考えました。 1. 課題発見(業務理解) 各自が担当する事業環境や業務プロセスを深堀りし、本質的課題の特定ができる   2. 解決具体化（テクノロジー理解） 生成AI技術の特性を正しく理解し、特定された課題に対して実現可能かつ効果的な手段を選択できる   研修全体像 研修は大きく3つのフェーズで実施しました。 フェーズ1：生成AI勉強会(全5回) 生成AIの基本的な利用経験(Copilotを活用した対話形式での利用)があることを前提に、より発展的な活用事例・最新動向を学ぶことを目的としたセミナー形式の勉強会です。IEエンジニアによる事例紹介やハンズオンに加え、住友商事社内で先行して積極活用している社員の方にも登壇いただくことで、参加者にとっても実践のハードルを下げ、生成AI活用のユースケースを身近に感じてもらい、関心を引き出すことができました。   フェーズ2：業務課題探索〜解説会 参加者には事前課題として、各自の業務プロセスおよび抱えている課題の棚卸を行ってもらいました。加えて、各自の課題に対して、それぞれの課題を生成AIで解決するのか、あるいはSaaSサービス等の別手段で解決するのかといった、具体的な解決策の検討にも取り組んでもらっています。その後、IEによる解説会を開催。IEの生成AIエンジニアやデータサイエンティストの目線から、適切な技術選定基準、および解決方法についての解説を行いました。   フェーズ3：Copilot道場・バイブコーディング道場(解決策具体化) フェーズ2で整理した業務課題と想定される解決方法のアイデアを持ち寄り、生成AIツール(Copilotと周辺サービス群等)を使った課題解決とバイブコーディングによるアプリケーション実装を体験しました。     Why バイブコーディング？ フェーズ3における道場の実施背景および進め方について少し詳細を説明します。IEの経験としても、汎用的な既製品のAIツールだけでは対応しきれない業務課題も存在し、ユーザーが自らの業務に合わせてアプリケーションやツールを個別に開発・調整して解決するケースが出てきます。一方、具体検討を進める上での業務担当者と開発者とのコミュニケーション負荷は大きく、構想段階で描かれる「全自動化」や「完全な自律型思考」といった理想の姿と、現在の技術水準やデータ環境において「現実的に実装可能なスコープ」との間にはギャップが生じがちです。 本道場では、実際にバイブコーディングを体験するプロセスを通じて、生成AIの最前線を肌で感じながら実現性への"勘所"を掴んでもらうことを狙い、プロトタイピング（アイデアのクイックな可視化と仮説検証）という手法を採用しました。   研修の成果 本研修は、実際の業務課題を題材に生成AIを活用するプロセスを自ら体験し、業務への取り入れやすさや効果を確かめることを目的として進めました。研修後、参加者からはアンケートを通じて以下のような声が寄せられました。   生成AIありきではなく、まず業務のボトルネックを丁寧に掘り下げ、自身の考えを言語化する能力の大切さを実感した   一度で完璧な成果物は出ないが、壁打ちを繰り返すことで精度を高められると感じた   計画に時間をかけるよりまず手を動かす方が有効で、「作る→試す→直す」のサイクルを回す姿勢を業務でも続けたい   8割まではすぐ作れるが、それ以上の完成度を求めると倍の時間がかかる、という費用対効果の勘所を、手を動かしたからこそ実感できた   主要ベンダー各社のツールに実際に触れたことで、各社の得意・不得意やセキュリティ上の制約を感覚的に理解できた これらの気づきは、本研修を端緒として、今後以下のような力・スキルへと通じていくものと考えています。   【言語化する突破力】 曖昧な理想を形にする「構造的対話スキル」   自分の構想やニーズを、相手（AIやエンジニア）に伝わる言葉に落とし込むスキル   現場の課題を丁寧に掘り下げ、実際に使う人の目線から本質的な解決策を考えるスキル   日常業務の中からAIで改善できそうなポイントを見つけ出し、課題として整理するスキル   意図を正確に伝えるプロンプト制御スキル   曖昧な指示をなくし、精度の高いアウトプットを引き出すために具体的に書くスキル   一発で完結させようとせず、壁打ちを繰り返しながら少しずつ精度を上げていくスキル   【形にする突破力】 まず作って試す「爆速プロトタイピングスキル」   作ったものに執着せず、必要とあればゼロから作り直せる柔軟さとスピード感   「作る→試す→直す」のサイクルを素早く回して、仮説の精度をどんどん上げるスキル   最初から完璧を目指さず、アイデアをさっさと形にして試してみるスキル 生成AIの特性を見極める設計スキル   一定以上の完成度を目指すとコストが急増することを念頭に置き、リターンに見合った落としどころを判断できるスキル   余分な機能を削ぎ落とし、本当に必要な価値に絞って作り上げるスキル   個別に開発すべきかどうかの判断も含め、既存ツールで代替できる可能性も踏まえた適切な技術選定の感覚   【繋がる突破力】 AIやエンジニアと対等に話せる「共通言語と翻訳スキル」   既存の自動化ツールと生成AIを、場面に応じてうまく組み合わせられる構成力   セキュリティの制約を前提条件として受け入れた上で、安全な使い方を考えられる力   主要ベンダー各社のツール特性を自らの手で触って理解し、状況に応じて使い分ける現場感覚   まとめ 生成AIのトレンドは目まぐるしく変わっており、ビジネス部門であっても新しいツールに触れ、「何ができて、何が難しいのか」を自ら試してみることは大切です。今回の研修でもハンズオンの時間を多く設け、まずはツールへの理解を深めてもらいました。 同時に私たちが意識したのは、ツールの習熟を進める中で、「自分の課題を言葉にし、素早く形にし、専門家と対話できる力」も一緒に育んでもらうことです。「実際にツールを動かす手」と「課題を具体化する思考」の双方が組み合わさることで、激しい技術トレンドに左右されず、どのようなツールが登場しても応用が利く本質的なスキルになると考えています。 また、今回はIEのメンバーが一体となって企画から運営まで携わりました。特に技術面で深い知見を持つエンジニアやデータサイエンティストが関わることで、参加者が持ち寄った業務課題に対し、実務に直結した技術的なフィードバックを届けることができたと感じています。本稿で解説した「3つの突破力」は、技術とビジネスの現場が交わるこの研修を通じてInsight Edgeなりに言語化したものです。 Insight Edgeには、エンジニアやコンサルタント、ワークショップデザイナーなど、多様なプロフェッショナルが在籍しています。総合商社が持つ広大なビジネスフィールドを舞台に、テクノロジーを通じて新たな価値を創出することに興味がある方は、ぜひカジュアル面談からお気軽にお問い合わせください。