こんにちは、メルカリの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/サーバレス設定
- DNS
- SSL証明書
- ロードバランサ
- セキュリティ
- ネットワークセキュリティ
- 認証認可
- シークレット管理
- 運用・監視
- オートスケーリング
- ヘルスチェック
- Datadog設定
- ログ収集
- ABテスト
- 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コンソールからすぐに確認できるため、運用の負担が大幅に軽減されます。
IAPで認証を「実装しない」
社内ツールで最も重要なことの１つはセキュリティですが、認証ロジックを自前で実装するのは大変です。
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つだと感じています。
2. データベース：Firestore と Google Spreadsheet
「高負荷なトランザクションが不要な社内ツールにおいて、月額数千円から1万円以上のコストがかかる Cloud Spanner や Cloud SQL はオーバースペックになりがちです。そこで、コストを最小限に抑える選択肢として Firestore と Google Spreadsheet が非常に役立ちました。
Firestore は、スキーマレスかつサーバーレスなデータベースで、完全従量課金のためスモールスタートに最適です。一方で、意外にも優秀な選択肢となるのが Google Spreadsheet です。
Spreadsheet を利用する最大の利点は、事実上のゼロコストで運用できる点にあります。Google Workspace 環境であれば追加費用はかかりません。Cloud Run の実行サービスアカウントに権限を付与するだけで、プログラムから容易に読み書きが可能です。
さらに、管理画面（Admin UI）を作る手間を省ける点も大きな魅力です。非エンジニアの担当者が直接データを閲覧・編集できるため、現場からは「使い慣れたツールで管理できてありがたい」という声も得られました。データ不整合のリスクという側面はありますが、数千行程度のマスタデータ管理などであれば、開発スピードとメンテナンス性を最優先した合理的な選択だと言えます。」
3. Streamlit
ツール開発において、現在は 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さんです。引き続きお楽しみください。
