AIタスクフォースにおける非AIタスク：AIツール開発の現場でこそ必要な「AI以外の」技術選定

AI タスクフォースにおける AI 以外のタスク：AI ツール開発の現場でこそ必要な「AI 以外の」技術選定

こんにちは、メルカリの AI Task Force でイネーブラー（Enabler）をしている @akkie です。

この記事は、Mercari Advent Calendar 2025 の 21 日目の記事です。

すでにご存知の方も多いかもしれませんが、現在メルカリは「AI-Native」をテーマに掲げ、AI を基盤として組織とプロダクトを抜本的に変革する取り組みを進めています。AI Task Force は、メルカリを AI Native な組織へと変革するために立ち上がった 100 名規模のチームで、Enabler は「各領域で AI Native な業務変革を主導する役割」とされています。

既存の AI/LLM ツールの活用はもちろん、プロダクトへの AI 組み込みや、マニュアル作業が多い業務の DX（デジタルトランスフォーメーション）推進など、その活動は多岐にわたります。

最近では、特に開発における生産性向上を目的として pj-double に多くのエンジニアが参加しています。

しかしこの記事では、生産性を上げるために「どう AI に効率的に仕事をさせるか」ではなく、AI を使わない部分の仕事について話したいと思います。

システムに AI を使わないに越したことはない

AI Task Force に居ながらこんなこと言っていいのか？と思うかもしれませんが、多くのエンジニアが、目的を達成するために「AI を使わないで済むなら使わないに越したことはない」に同意するのではないでしょうか。

よくあるジョークとして、コーディングしているエンジニアの様子を想像してみて、と非エンジニアの人に聞くと、目まぐるしく手を動かしてキーボードにコードを打ちこんでいる様子を想像する、けれど実際のエンジニアを見てみると、キーボードから手を離し頭を抱えながら、画面に大量に表示されたエラーをジッと見つめ原因を探っている時間の方が何十倍も長いということがあります。これは事実です。

最近ではまず AI が 70% 正しいコードを書いてくれるようになった分、なおさら人間はコードを打ち込むよりも「頭を抱えてコードが動かない問題の原因を探っている」時間の方が長くなったかもしれません。使っているライブラリの古いバージョンを前提に AI がコードを書いてきたり、サードパーティの API 仕様を理解していなかったり、間違える要素はいくらでもありますし、AI の出力は下手に正しそうに見える分デバッグにも時間がかかります。

システム開発はいわば人間が行ってきたことを自動化することが仕事です。メルカリのアプリ開発も、これまで街中のフリーマーケットで人と人との間で行われていた商売をシステムで行うための大きな自動化に取り組んでいるとも言えるでしょう。

AI はその大きな助けになってくれますが、人間が AI に正しく意図を伝えられていないだけというケースも含めてまだ「70％正しい」くらいの出力を返してくるのが現状です。

それと比べて、シェルにコマンドを打ち込んだり、コードを Docker イメージ上で動かす作業はほぼ 100%(もちろん環境要因で動かなくなるときはあるでしょうが) 常に同じレスポンスを返してくれます。ターミナルを開いて "echo $(( 100 + 200 ))" と打てばいつだって画面には 300 と表示されるし、お金もかかりません。

「100+200 の答えが知りたい」という時に、ChatGPT を開いて「100+200 は？」と聞く人はいませんよね。たとえ聞いても ChatGPT は多くの場合正解を返してくるでしょうが、コストパフォーマンスや精度を考えるとこんなことを AI に聞くコードをシステムに組み込む人は居ないわけです。

また、数珠つなぎに AI に仕事を連携させていくと、その掛け算で精度は下がり、すぐに使い物にならなくなるでしょう。

つまり、仕事 (特にシステム内で行うもの) は「AI を使わずとも自動化できるのであれば、使わないに越したことはない」ということが前提にあるはずです。もちろん AI の精度を上げる努力も必要ですが、決定論的なロジックで解決できる課題に AI を持ち込むべきではありません。AI は確率論だけれど、システムはできる限り決定論であるべきです。

AI Task Force というチームに所属しているので、色んな組織から「これ、AI で解決できませんか？」という相談を受けます。しかし具体的に話を聞いてみると、「それは AI 使わなくても解決できますね」という回答になることがよくありました。「アクセスログから◯◯の売上分析をしたい」、「人事システムに溜まった△△のデータを可視化・検索したい」、などはその例でしょう。AI にそれらをさせるのではなくそれらを実現するコードを AI に書かせる、という意味ではたくさん AI を利用することにはなりますが、一度きりでは済まないような作業を AI 自身にやらせるのは悪手だと考えます。AI に魚を持ってこさせるのではなく、釣り竿を作らせるのが AI の良い使い方と考えます。

とにかく、どうしても AI にしか解決が難しい課題にのみ AI を使いたい。私にとってこの半年の仕事は、いわば「いかに AI を使わないで済むかを考える」ことでした。

また、AI を使うかどうかは内部の実装の話だけではなく、ユーザとのインタフェースにも同じことが言えます。何にでも AI を使うことがもてはやされる時代ですが、あえて AI を使わない選択肢をとることで向上する生産性もあります。あなたが提供しようとしている価値に、本当に自然言語によるユーザとのインタフェースは必要でしょうか？mcp サーバは必要でしょうか？

UNIX コマンドの多くが対話型のコマンドを避け、パイプされた他のコマンドとの組み合わせによって自動化が容易になったように、自分の作っているものに自然言語による対話型インタフェースが必要かは常に慎重な見定めが必要です。

社内ツール開発における「9 割」の正体

たとえ AI を使って業務改善のためのツールを開発することが決まっても、大半の時間は AI と全く関係ないところに使われていることにも気が付きました。特にインフラ周りです。

LLM が当たり前に使われるようになるずっと前から、AI を使ったプロダクト開発においては「データの収集やインフラ整備が工数の 9 割を占め、モデル自体の設計・改善は 1 割程度である」と言われてきました。

この現実は、LLM が登場し AI 技術が進化しても変わってないように感じています。

たとえば機械学習モデルが実際に価値を生む API として、高可用性・低遅延・スケーラビリティを維持して稼働し続けるためには、モデルの学習や評価よりも多くの、複雑なインフラおよび MLOps 作業が不可欠になります。

具体的にタスクを挙げてみます。

基盤・ネットワーク：コンテナ化

Kubernetes/サーバレス設定

セキュリティ ネットワークセキュリティ

運用・監視 オートスケーリング

DevOps CI/CD パイプライン

IaC (Terraform/CloudFormation)

当然、これに加えて機械学習に与えるためのデータの収集のパイプラインや、BigQuery などの Data Ware House（データウェアハウス）整備も必要になります。

こうしたタスクも当然 AI の力で楽にはなるのですが、インフラ周りの設定は複数の Github Repository、手動作業、目視での確認、試行錯誤などが必須となり、どうしても時間がかかってしまいます。GitHub Actions を 1 行直しては試す、Terraform の設定を 1 行直しては試す、Kubernetes マニフェストを 1 行直しては試す、のような作業に膨大な時間を使った経験があるエンジニアも少なくないでしょう。

つまり、AI によって業務を改善しようと考えるときに、アプリケーションロジックを AI に効率的に書かせることだけではなく、こうしたインフラ・基盤周りの作業を決定論的に効率化しないことには生産性は大きく上がらないのではないかと考えています。

メルカリの AI Task Force では、各組織（エンジニアのいないチームを含む）に Enabler が 1〜2 名アサインされ、組織の業務を改善する助けをするというスタイルをとっています。

つまり、上記のタスクを基本的にはたった 1〜2 名で完遂しなければなりません。

「ここは SRE にお願いして…」「ここは ML エンジニアに…」と専門家に依頼している時間はありませんし、非エンジニアの方々の課題を解きほぐし、仕様に落とし込む PM（プロジェクトマネージャー）のような役割も求められます。そもそも自分の知らない領域のチームのドメイン知識を手に入れるためにも多くの時間が必要でしょう。

ここにさらに「AI 固有の悩み」が乗ってきます。モデル選定、コンテキストエンジニアリング、そもそも Google ADK や Pydantic AI などライブラリの進化が早くて追いつくのが大変…など。

そこで、私が半年間 AI Task Force でイネーブラーとして活動している間、そうした少ない人数で社内ツールを作るために頻繁に用いた構成を紹介します。

前提として、社内ツールにはメルカリのメインプロダクト、Microservices（マイクロサービス）ほどのスケーラビリティや厳密な可用性は求められません。求められるのは「開発スピード」「メンテのしやすさ」「低コスト」です。

Google Workspace と Google Cloud を社内で使っていることが前提になっています。

1. Cloud Run + IAP (Identity-Aware Proxy)

Google Cloud 環境において、私が社内ツール基盤として圧倒的に頻繁に用いたのが Cloud Run と IAP (Identity-Aware Proxy) の組み合わせです。

なぜ Cloud Run なのか？

Cloud Run を利用する主な理由は、その優れたコスト効率、スケーラビリティ、そしてシンプルなデプロイに集約されます。

Cloud Run の最大の利点の一つは、その高いコスト効率です。リクエストがないときは実行インスタンスがゼロになり、その間は課金が一切発生しません。これは、夜間や休日などアクセスが少なくなる時間帯がある社内ツールなどにとって、特に大きなメリットとなります。

また、どれだけ利用者が集中したとしても、Cloud Run は自動で必要な数のコンテナを起動し、トラフィックの負荷に瞬時に対応するスケーラビリティ（拡張性）を備えています。これにより、ピーク時のアクセス集中によるサービス停止やパフォーマンス低下の心配をする必要がなくなります。

Cloud Run を使えばシンプルなデプロイが可能です。アプリケーションをパッケージ化した Dockerfile さえ用意すれば、あとは簡単なコマンド一つでデプロイが完了します。「レプリカセット！」「ライブネスプローブ！」「ホリズンタルポッドオートスケーラー！」といった Kubernetes の呪文も覚える必要はありません。

また、DNS や SSL 証明書の管理から解放されるだけでなく、サービスで重要な基本的なメトリクスやログも自動で収集されます。これらはすべて GCP コンソールからすぐに確認できるため、運用の負担が大幅に軽減されます。

社内ツールで最も重要なことの 1 つはセキュリティですが、認証ロジックを自前で実装するのは大変です。

IAP (Identity Aware Proxy) を使えば、Google Workspace アカウントに基づいたアクセス制御をインフラ層で強制できます。アプリ側では特定のヘッダを見るだけでユーザーを特定でき、認証ロジックを書く必要がなくなります。

Terraform で Load Balancer やバックエンドサービスを構成するための複雑なネットワーク設定を組むと長い時間のかかる作業が、Cloud Run なら以下のコマンドだけで「社内限定公開」の環境が整います。

Cloud Run へのデプロイ（IAP 有効化オプション付き）

gcloud beta run deploy ${SERVICE_NAME} \

--no-allow-unauthenticated --iap \

--platform managed \

--project=${PROJECT_ID} \

--service-account=${SA_EMAIL} \

--region=asia-northeast1 \

--image=${IMAGE_ID}

IAP へのアクセス権限付与（社内ドメインや特定グループのみ許可）

gcloud beta iap web add-iam-policy-binding \

--project=${PROJECT_ID} \

--member="例:group:all-members@mercari.com" \

--role=roles/iap.httpsResourceAccessor \

--region=asia-northeast1 \

--resource-type=cloud-run \

--service=${SERVICE_NAME}

これだけで、Artifact Registry に上げてあるコンテナが、社内メンバーだけがアクセス可能な状態で立ち上がります。(beta なので今後 GA になった際にはコマンドが変わる可能性があります)

Vertex AI (Gemini) へのアクセスも簡単

AI をツールから使う上で面倒なことの一つが、API トークンの管理です。

Cloud Run ならば、Cloud Run の実行 Service Account に roles/aiplatform.user を付与しておくだけで、API キーの管理やローテーションを気にすることなく Gemini を利用可能です。

from google import genai # 認証情報が環境から自動取得されるため API Key の指定は不要

client = genai.Client(vertexai=True, project="your-project-id", location="us-central1")

model = "gemini-2.5-flash-lite"

response = client.models.generate_content(

model=model,

contents="元気ですか？"

)

print(response.text)

n8n や Dify などのノーコードツールも魅力的ですが、将来的な要件変更の柔軟性を考えると、Cloud Run によるコードベースの開発は「セットアップコストを抑えつつ、自由度を確保する」ための最適解の 1 つだと感じています。

1. データベース：Firestore と Google Spreadsheet

「高負荷なトランザクションが不要な社内ツールにおいて、月額数千円から 1 万円以上のコストがかかる Cloud Spanner や Cloud SQL はオーバースペックになりがちです。そこで、コストを最小限に抑える選択肢として Firestore と Google Spreadsheet が非常に役立ちました。

Firestore は、スキーマレスかつサーバーレスなデータベースで、完全従量課金のためスモールスタートに最適です。一方で、意外にも優秀な選択肢となるのが Google Spreadsheet です。

Spreadsheet を利用する最大の利点は、事実上のゼロコストで運用できる点にあります。Google Workspace 環境であれば追加費用はかかりません。Cloud Run の実行サービスアカウントに権限を付与するだけで、プログラムから容易に読み書きが可能です。

さらに、管理画面（Admin UI）を作る手間を省ける点も大きな魅力です。非エンジニアの担当者が直接データを閲覧・編集できるため、現場からは「使い慣れたツールで管理できてありがたい」という声も得られました。データ不整合のリスクという側面はありますが、数千行程度のマスタデータ管理などであれば、開発スピードとメンテナンス性を最優先した合理的な選択だと言えます。」

ツール開発において、現在は Next.js がデファクトスタンダードと言えますが、社内ツールであれば Streamlit を採用することにも大きなメリットがあります。

最大の利点は、開発速度の圧倒的な速さと学習コストの低さです。Streamlit を使えば、データアナリストやエンジニアが Python を書く延長線上で UI を構築できます。フロントエンドとバックエンドの境界を意識せず、入力ウィジェットやグラフ、チャットインターフェースなどを数行で実装できるため、迅速な改善が求められる現場で真価を発揮します。将来的に非エンジニアがツール制作に携わる際や、AI エージェントが台頭して「ロジックさえあれば UI はチャットで十分」となる時代を見据えても、Python で完結するライブラリを選んでおくのは有利な選択です。

また、Python エコシステムとのシームレスな統合も無視できません。Pandas などのデータ処理ライブラリと標準で連携できるため、Next.js のように Python バックエンドとの間に複雑な通信レイヤーを設ける手間が省けます。同一の Python 環境内でデータを直接扱い、即座に UI へ反映できるシンプルさは、デバッグやメンテナンスの工数削減に直結します。

他の Python 製 UI ライブラリも検討しましたが、現時点では Streamlit が最も完成度のバランスに優れていると感じています。もちろん API 開発が必要なケースでは他の選択肢が必要になりますが、「開発効率」を最優先する社内ツールにおいて、Streamlit は非常に強力な武器になります。

もちろん、上記の技術を選んだことで諦めることにした部分もあります。

ミリ秒単位の「サクサク」した操作感 Cloud Run がコールドスタートするときには数秒の遅延が発生します。また、Streamlit で複雑なことをし始めるとどうしても動きがモッサリして、Cache や Session の管理が厄介にもなります。

厳密なトランザクション管理や集計クエリ アクセス数が少ない社内ツールでは大きな問題は起きないだろうと考え、諦めました。

サービスの常時稼働 Cloud Run には常時稼働するオプションもありますが、一気にコストが上がり、従量課金のメリットが消え去ります。常に event を Listen するアプリやバックグラウンドでの重い非同期処理にはコストパフォーマンスが良くないでしょう。

AI-Native な組織変革を達成するには、エンジニアと非エンジニア組織の協力が不可欠です。

この半年間、私はコードを書くだけでなく、現場の課題を聞き出し、それを技術で解決する「技術コンサルタント」のように働く時間が多かったように思います。

非エンジニアと密に連携し、効率よく価値を届けるためには、彼らにとってもフレンドリーな技術を選択肢に入れ、柔軟性の高い技術を選択し、また常に「本当に AI を組み込むことは必要なのか」を見極めることも大事です。

また、上述のような技術を使っても、まだ厄介なところは「CI/CD」で、個人的に改善しようとしているところです。 プルリクエストが作られれば自動的に Preview URL が生成され、マージしたら本番環境にデプロイされる。環境変数の値を変更したいときに数クリックでサクサクと変更ができる。まだまだ今は手動デプロイをすることも多いですが、そういった PaaS 体験を上述の技術と合わせて達成することで格段に生産性が上がるだろうなと感じています。

進化の早い AI を活用し、現場の業務を最速で効率化していくフェーズにおいては、サーバレスソリューションをフル活用して「明日から使えるツール」を届けてみるのも悪くないのではないでしょうか。

明日の記事は@Kahla さんです。引き続きお楽しみください。

Advent Calendar

Related article

2025/12/25 AI-Native という選択 ー 正解のない時代に、メルカリが選んだ指針

Author: kimurashunya

2025/12/23 Cursor でプログラミング言語を学び直す方法——AI 駆動学習の 4 ステップ

2025/12/20 LLM を用いたおしゃべり機能「しゃべるおさいふ」のバックエンド設計

Author: kobaryo