AIを「手段（道具）」として使うか、「目的（システム機能）」として組み込むか

最近、AIをシステムに組み込む案件が増えている。だが、この仕事をしていて、いつも自分の中で最初に確認していることがある。

このAI、「手段（道具）」として使おうとしているのか、それとも「目的（システム機能）」として組み込もうとしているのか、という問いだ。

短く「手段」「目的」と呼んでしまうと、この違いの重みが伝わりにくい。だから今回は、あえて長い言葉のまま書く。「AIを“手段（道具）”として使う」のか、「AIを“目的（システム機能）”として組み込む」のか。この2つは、概念も目的もまったく異なるものだと思っている。

2つの概念の決定的な違い 現場での混乱を防ぐためにも、この2つははっきりと区別して整理する必要がある。

「AIを“手段（道具）”として使う」というのは、いわゆるAI-Assisted Developmentのことだ。主体はあくまで開発者、つまり人間であり、AIは開発者の生産性を上げるためのツールに過ぎない。AIが動くのは開発現場、つまり開発者の手元だけで、本番環境そのものには影響を与えない。Cursor、GitHub Copilot、ChatGPT、Claudeを開発の相棒として使う、というのがこの典型である。目的は、開発の高速化、コスト削減、品質向上だ。

一方、「AIを“目的（システム機能）”として組み込む」というのは、AI-Powered SystemあるいはAI Applicationと呼ばれるものだ。この場合の主体は開発者ではなく、エンドユーザー——実際にそのシステムを使う利用客や社員——であり、AIはそのエンドユーザーに直接価値を提供する機能そのものになる。AIはシステム内部、つまり本番環境に組み込まれて動作する。OpenAI APIやClaude APIをはじめとする各種AIエンジン、Hugging Faceの各種モデル、あるいは自社で学習させたモデルなどがこれにあたる。目的は、高度な判断、予測、生成、自動応答といった、サービスそのものの実現である。

この2つは、開発者のための道具か、エンドユーザーのための機能か、という主体からしてまるで違う。ここを混同したまま話を進めると、後になって必ずどこかで揉める。

「使えるから使う」の危うさ 生成AIが世に出て、猫も杓子もAIを組み込みたがる時代になった。相談を受けていても、「AIで何かできませんか」という話から始まることが少なくない。

だが、これは順番が逆だと思っている。本来は、解決すべき課題があって、その解決策の一つとしてたまたまAIが最適だった、という順番でなければならない。課題が先、AIは後だ。

「AIを使っていること」自体が目的化してしまうと、ろくなことにならない。判断の精度も、コストも、保守性も度外視して、とにかくAIを噛ませておけば先進的に見える、という発想は、システムとしては本末転倒である。

ソフトハウスの現在地 今、世の中の大半のソフトハウスは、「AIを“手段（道具）”として使う」段階にとどまっている。開発現場でCursorやGitHub Copilotを使いこなす、というレベルだ。それ自体は悪いことではないし、必要な一歩でもある。だが、そこで止まっているソフトハウスがほとんどというのが、今の業界の現在地だと感じている。

一方で、「AIを“目的（システム機能）”として組み込む」というのは、まったく別のスキルセットを要求される話だ。開発現場でAIを使いこなせることと、本番環境の中核にAIエンジンを据えて設計・実装できることの間には、はっきりとした断絶がある。

ジェイ・スピリッツは、もちろん開発現場でAIを道具として使う場面もある。だが本質は、そこではない。スクレイピングで20年以上かけて培ってきたデータ収集の技術、そこから積み上げたBIGDATAの扱い、機械学習による分類・予測、そして汎用LLM/AIエンジンAPIの活用、さらにローカルLLM、AIオーケストレーションによる複数モデル・複数処理の統御。この一連の技術の系譜が、そのまま「目的として組み込む」側のスキルに地続きになっている。

つまり、うちにとってAIエンジンは、ある日ふって湧いた新しい道具ではない。長年のデータ処理・解析の延長線上に、必然として現れたピースの一つに過ぎない。この系譜があるからこそ、AIを「目的（システム機能）」として、システムの中核に据える設計ができる。ここが、AIを「手段（道具）」として使い始めたばかりの多くのソフトハウスとの、決定的な違いだと思っている。

レガシーになる、という感覚 もう一つ、AIをシステムに組み込む仕事をしていて、強く感じることがある。今まで当たり前だと思っていたシステムやアプリの作り方そのものが、急速にレガシーになりつつある、という感覚だ。

これは大げさな話ではない。検索窓とプルダウンとボタンを並べて、決まった手順を踏ませる。そういうUIとフローの設計自体が、AIが文脈を理解して先回りできる時代には、遠回りな作り方になってしまう。今まで何十年も「正しい設計」として積み上げてきたものが、前提から崩れていく感覚である。

これは技術力だけの話ではない。むしろ、ここから先は「何を作るか」を思い描く力、つまり想像力の勝負になってくると思っている。

今までは、要件を積み上げて、機能を分解して、画面遷移を設計すれば、それなりの形になった。だが、AIを前提にシステムを組むとなると、そもそも画面や手順そのものが要らなくなる場面が出てくる。ユーザーが欲しいのは「機能」ではなく「結果」であって、その結果に至る道筋をAIが動的に組み立ててくれるなら、今まで作り込んできたUIやフローは、丸ごと不要になりかねない。

だからこそ、上流の設計者に求められるのは、既存のシステムの形をなぞる力ではなく、白紙の状態から「これがあったらどうなるか」をイメージする力だと思う。技術がどこまでできるかは、後から追いつけばいい。先に必要なのは、今までの常識を一旦手放して、真っさらな状態で「何を作るべきか」を思い描けるかどうかだ。

40年、この業界の変化を見てきたが、ここまで前提が根こそぎ変わる感覚は、正直これが初めてかもしれない。

結局、これは技術の話ではない うちが請ける仕事では、最初に「これは“手段（道具）”として使うのか、“目的（システム機能）”として組み込むのか」を必ず言語化するようにしている。ここが曖昧なまま実装に入ると、後になって「なぜこんなに複雑なんですか」とか、逆に「なぜAIエンジンを組み込まないんですか」とか、揉める種になることが目に見えているからだ。

AIは便利な道具にもなれば、システムの核にもなる。ただし、そのどちらを選んでいるのかを、開発者自身が自覚して扱ってこそ、初めて正しい設計と言える。そして、その先にある「何を作るか」を描けるかどうかは、結局のところ技術力ではなく想像力の話なのだと思う。