汎用ツールを"小さな専用ツール"で置き換える — 生成AI時代のBuild vs Buy再考

こんにちは。認証チームのいまひろです。

これまでのブログでは、「できる限り多くの作業を Claude Code をインターフェースとして、スキル化して実行する」 というチーム方針のもと、Gherkin テストの自律実行やドキュメント生成の仕組みを紹介してきました。

Claude Codeをチーム開発の統一インターフェースに — Gherkinテストの自律実行で"見えない作業"をゼロにする

今回は少し毛色を変えて、開発を支える「ツール」そのものの話です。チームで長く使ってきた汎用の既製ツールを、生成 AI に実装させた小さな専用ツール（purpose-built tool）で置き換えた話と、その背景にある 「Build vs Buy の計算が生成 AI で変わりつつある」 という考察を書きたいと思います。

要約すると——生成 AI で「作るコスト」が激減し、サプライチェーン攻撃の激化で「既製ツールを使い続けるリスク」が上がった今、開発現場の小さな汎用ツールは自作の専用ツールで置き換えることが合理的な選択肢になりつつある、というのが本記事の主張になります。

汎用ツールの「機能の多さ」が、負債に見えはじめた

きっかけは、チーム内で使っていた 2 つの既製ツールへの、小さな、しかし毎回発生する不満でした。

事例1: forward proxy（Squid）

スマホの実機から、開発マシン上のローカル環境や、/etc/hosts を書き換えて向き先を変えた検証環境にアクセスしたい——多くの現場にある場面だと思います。私たちは開発マシン上に Squid を立てて、スマホの HTTP プロキシとして経由させる方法を使ってきました。

Squid は実績のある素晴らしいソフトウェアですが、「手元の検証端末を一時的に通す」だけの用途にはオーバースペックで、使うたびに回り道が発生していました。

/etc/hosts の書き換えが即座に反映されない。Squid は hosts ファイルの内容を自前のキャッシュに読み込むため、書き換えるたびに squid -k reconfigure（設定の再読み込み）が必要です。検証中は hosts を頻繁に書き換えるので、「変わらない…あ、reconfigure 忘れてた」を何度も踏みます
設定項目が膨大。キャッシュ、ACL、認証ヘルパー、階層構成……この用途で実際に使うのはごく一部なのに、設定ファイルの全体を把握していないと安心できません
設定ミスがそのまま脆弱性になる。http_access の記述順を誤ると意図せずオープンプロキシとして動き得ます。「使わない機能」の分だけ、「安全に設定できているか」を確認すべき範囲が広がります

事例2: OAuth2 の動作検証 CLI

もう 1 つは、自社の OAuth2 認可サーバのリリース前検証で使用していたツールです。認可コード + PKCE のフローを実際に流してトークンを取得し、API 疎通まで確認する作業で、外部の OSS の汎用 OAuth2 クライアント CLI を使ってきました。

この CLI は authorization code / client credentials / device / token exchange など主要な grant をほぼ網羅し、高度なセキュリティプロファイルにまで対応した強力な汎用ツールです。しかし、検証対象の認可サーバがサポートするのは authorization_code と refresh_token の 2 つだけ。毎回の検証は「膨大な選択肢の中から正しいオプションの組み合わせを組み立てる」ことから始まります。

さらにネックとなっていたのが AI エージェントへの組み込みにくさです。この検証を Claude Code のスキルとして自動化していたのですが、「複数コマンドを正しく組み立て、順に実行し、出力を解釈する」手順をすべてスキル定義に書き下す必要があり、汎用 CLI の自由度がそのまま組み込みの煩雑さになっていました。

1 時間足らずで「やりたいことだけ」のツールができた

そこで、この 2 つを自作ツールに置き換えました。実装はすべて生成 AI（Claude Code）によるもので、開発者が行なったのは要件を仕様にまとめて伝えることと、出てきたコードをレビューすること。どちらも初版は 1 時間もかからずに、チーム内での運用として実用レベルのものが完成しました。

forward proxy の置き換え: 標準ライブラリのみ・約 350 行

Go の標準ライブラリだけで書かれた、約 350 行・依存ライブラリゼロの forward proxy です。

HTTP は絶対 URL の転送、HTTPS は CONNECT のトンネル中継だけ
名前解決は OS のリゾルバをそのまま使う。/etc/hosts の書き換えは、再起動も再読み込みもなしに次のリクエストから反映される
設定はコマンドラインフラグが数個だけ。設定ファイルは無い

そして、専用ツールだからこそ入れられた仕様が safe-by-default（安全側に倒した既定値） です。

$ ./proxy
  Mode: LOCAL-ONLY (safe default)
        Only this machine itself can use the proxy.
        Pass -allow <cidr> to accept external clients.
  Listen: 127.0.0.1:3128

許可する送信元 CIDR を明示しない限り loopback にしかバインドしない、という挙動を最初から仕様に組み込みました。共用の Wi-Fi で誤って起動しても、外部からは一切使えません。汎用ツールでは「設定を正しく書かなければ安全にできない」ものが、専用ツールではこちらの意思で「何もしなければ安全」に倒すことができます。

OAuth2 検証の置き換え: YAML 1 枚 → レポートまで自動

もう 1 つは「YAML 設定 1 枚を渡して起動するだけ」に特化した検証ツールです。起動すると次を自動で流します。

認可コード + PKCE フローでトークン取得（ブラウザはシークレットウィンドウで自動起動し、Cookie を残さない）
取得したアクセストークンで API 疎通確認
refresh_token grant でトークン更新 → 再疎通確認
PASS / FAIL のテーブルをレポートとして出力

  STEP                           STATUS   ELAPSED
  ------------------------------------------------
  authorization_code             PASS     4.8s
  api_check                      PASS     213ms
  refresh_token                  PASS     412ms
  api_check_after_refresh        PASS     207ms
  Overall: PASS

対象サーバの仕様（対応 grant、クライアント認証方式、discovery 非対応、refresh_token が rotate されない等）はすべてツール側に実装されているので、オプションの組み立てはもう存在しません。Claude Code のスキルは「設定を引数に起動し、レポートを読む」だけになり、AI エージェントへの組み込みが一気に単純になりました。

どちらのツールも単一の Go バイナリとしてチームに配布しています。実行時依存がなく、パッケージマネージャ経由で意図せず更新されることもないので、「昨日と同じバイナリが今日も同じように動く」ことが担保しやすい形です。

Build vs Buy の計算が変わった

「その程度のツール、昔から作れたのでは？」——その通りです。ただ、従来は作らないことが合理的な選択になることが多かったと思います。数日〜数週間の開発コストと、その後ずっと続く保守コスト（作った人しか直せない問題を含む）を考えると、多少の回り道を飲んで実績ある汎用ツールを使う方が理にかなっていたからです。

この前提が、生成AI時代に入り、両側から崩れてきています。

※ Squid も先の OAuth2 クライアント CLI も無償の OSS であり、「Buy（買う）」という言葉はそぐわないように見えるかもしれません。ただ Build vs Buy の議論における「Buy」は、外部の既製ソリューションを採用すること全般を指すのが一般的で、無償の OSS もそこに含まれます。ライセンス費用がゼロでも、導入・習熟・設定・更新への追随・供給元リスクの受容といったコストは確かに払っているからです。本記事でも「Buy = 既製ツールを採用して使うこと」の意味で使っています。

「作る」コストが桁で下がった

今回の 2 つのツールは、要件を伝えて生成 AI と対話しながら、それぞれ 1 時間もかからずに実用レベルに達しました。

速さの理由は、生成 AI のコード生成能力だけではありません。汎用ツールを使い込んできたからこそ、必要な機能と足りない機能が最初から分かっているのです。つまり置き換えの時点で要件定義は事実上終わっており、シンプルで必要十分な仕様をすぐに仕様書に落とすことができます。仕様が明確でコンパクトなら、生成 AI はそれをほぼ修正のいらない状態で形にしてくれます。

「使う」リスクが目に見えて上がった

一方で、エコシステム全体への依存度が高まる中、「多様な機能を備えた人気の汎用ツール」を使い続ける管理コストやセキュリティリスクは相対的に上がっています。ここ 1 年ほどのソフトウェアサプライチェーン攻撃は、規模も手口も明らかに変わりました。

2025 年 9 月、npm の chalk / debug を含む 18 パッケージがフィッシングによるメンテナアカウント乗っ取りで改ざんされました（日本語解説: gihyo.jp、@IT）。合計で週 26 億ダウンロードという、事実上「ほぼ全員が間接的に依存している」規模のパッケージ群です
同月に出現した自己増殖型ワーム Shai-Hulud（日本語解説: SIOS Tech Lab、Codebook）は、開発者の認証情報を窃取して別パッケージへ自動伝播し、CISA が警告を出す事態になりました。その後も 2.0、3.0 と亜種が続いています
さらに生成 AI 固有の新型攻撃として slopsquatting（日本語解説: トレンドマイクロ）が登場しています。LLM がもっともらしく幻覚する存在しないパッケージ名を先回りして登録しておき、AI が生成したコードや手順を鵜呑みにした開発者・エージェントにインストールさせる手口で、調査では生成コードサンプルの約 2 割にハルシネートされたパッケージ名が含まれていたと報告されています

注意したいのは、これは「外部ツールが危険になった証明」ではないことです。人気のある汎用ツールは多くの利用者を一度に狙える攻撃価値の高い標的であり、だからこそ狙われ続ける、という構造の話です。逆に、チーム内だけで使う自作ツールは配布母数が小さく攻撃価値がほぼなく、依存を最小化すれば攻撃経路そのものが細い。汎用ツールの最大の Pros だった「みんなが使っている」が、サプライチェーン攻撃の文脈では Cons に反転する——この非対称性が、Build vs Buy の計算を変えるもう一つの要因になっています。

Pros / Cons 整理: 生成 AI の前後で何が変わるか

観点	既製の汎用ツール	自作の専用ツール（生成 AI 以前）	自作の専用ツール（生成 AI 以後）
初期コスト	◎ 入れるだけ	✕ 数日〜数週間	◎ 1 時間足らず
機能適合	△ 設定で寄せる・妥協と回り道	◎ やりたいことだけ	◎ やりたいことだけ
攻撃対象領域	△ 使わない機能の分だけ広い	◎ 最小	◎ 最小
供給元リスク	○ → △ サプライチェーン攻撃の主戦場に	◎ 自前	◎ 自前
品質・実績	◎ 枯れている	△ 自前でバグと戦う	○ テストも AI で書ける（ただし過信は禁物）
保守	○ upstream 任せ（更新追随の判断は必要）	✕ 作者しか直せず属人化	○ AI がコードを読める・直せる

生成 AI 以前は、自作側の「初期コスト ✕」「保守 ✕」が決定的で、汎用ツール一択になるのが普通でした。生成 AI 以後は、この 2 つの ✕ がほぼ消えます。特に保守については、「そもそもAIがコードを書き、豊富なドキュメントやコメントを残すことができるので、AI にコードを読ませれば経緯も直し方も説明できる」ことが属人化の構造を変えつつあります。数百行の専用ツールなら、コード全体が AI のコンテキストに収まることも効いています。

同時に、汎用ツール側では「供給元リスク」の欄が悪化しました。updates を取り込み続けることが前提のエコシステムでは、上に挙げたような侵害が自分の手元に届くかどうかを、利用者側でコントロールしにくいからです。

とはいえ、全部を自作すべきではない

誤解のないように、割り切りと注意点も書いておきます。

枯れた部品は作らない。今回自作したのはあくまで「組み合わせ」の層です。TLS、暗号、HTTP プロトコルの実装そのものは Go の標準ライブラリに任せており、そこを再発明する気はありません
「AI が書いたから安全」ではない。自作ツールにも人間のセキュリティレビューは通します。経験上効くのは、レビューを頑張ること以上に、safe-by-default を最初に仕様として決めてしまうことでした。「誤操作したときに安全側に倒れる既定値」は後付けしにくいので、AI に要件を伝える段階で盛り込みます
チーム内ツールだから成立する。外部公開するとなれば、ドキュメント、互換性維持、脆弱性報告窓口と、話はまったく別のものとなります。今回の判断は「利用者が手の届く範囲にいる」ことに強く依存しています
本当に高機能が必要なら既製一択。大規模なキャッシュ運用や認証基盤との統合が要件なら、Squid のような汎用ツールの価値は揺らぎません

Shadow IT とは別軸の話——だからこそスコープを絞る

もう 1 つ、この流れを「AI で作れるのだから、ツールは何でも内製すればよい」と読むと、別の問題に突き当たります。Shadow IT——組織の統制の外で作られ・使われるソフトウェアの問題です。作るコストの低下は、放っておけばそのまま Shadow IT の増殖圧力になるわけです。

本記事で勧めているのは、それとは軸の異なる話だと考えています。ポイントは、対象を開発現場の小さなツールの置き換えに意図的に絞っていることです。

業務データ・顧客データに触れない。動くのは開発者の手元だけで、置き換え前の汎用ツールと扱う情報の範囲が変わらない
利用者・作者・保守者が同じチーム。影響範囲がチームの外に出ず、「作った人がいなくなって誰も分からないシステム」問題の構造にならない
コードごとチームのリポジトリでレビュー・管理される。「誰も中身を把握していないツール」を増やさない

むしろ視点を変えると、各メンバーがパッケージマネージャで思い思いに入れて、バージョンも設定も誰も把握していない既製バイナリ群の方が、「管理外のソフトウェア」という意味ではよほど Shadow IT 的です。数百行の自作ツールをコードごとリポジトリに乗せることは、チームのソフトウェア資産の可視性をむしろ高める方向に働きます。

逆に言えば、作ったツールが業務データを扱いはじめたり、利用者がチームの外へ広がりはじめたりしたら、それはもうこのスコープの外です。そこから先は通常の社内システム開発としてのガバナンスの議論——まさに Shadow IT の論点——として、別途扱うべきものだと思います。

まとめ

「汎用ツールを使うか、専用ツールを作るか」。これまで何十回と繰り返してきたこの議論の前提が、「作るコスト」と「使うリスク」の両面から、生成 AI によって根底からひっくり返りつつあるのを感じています。

作るコスト: 数週間 → 1 時間足らず。既に汎用ツールを使っていれば必要十分な仕様も見えている。保守の属人化も AI がコードを読めることで緩和
使うリスク: 人気汎用ツールはサプライチェーン攻撃の主戦場になり、slopsquatting のような AI 固有の攻撃も出現

その結果、これまで「開発・運用コストに見合わない」と一蹴されてきたチーム内の専用ツールという選択肢が、現実的なラインに入ってきています。私たちの場合は、forward proxy と OAuth2 検証という 2 つの置き換えで、日々の回り道と「設定は本当に安全か」という不安を、数百行の見通せるコードに交換できました。

もちろん、すべてを作るべきではありません。ただ、「汎用ツールの機能の 5% しか使っていない」「特定のシーケンスに組み込むために毎回回りくどいことをしている」——そんなツールが手元にあるなら、「置き換えるメリットはあるのか」を生成 AI 前提で見積もり直してみる価値は十分あると思います。かつては即答で「Buy」だった問いの答えが、変わっているかもしれません。