結局、どのAIが必要なのか？

ChatGPT、Claude、Gemini、専門AI、Coding Agent、Local AI。まず目的から決める。

AIを選ぼうとすると、最初に製品名が並びます。

でも、欲しいのはAIそのものではありません。

欲しいのは、調べ終わった資料、直ったコード、完成した文章、減った作業時間、外へ出せないデータを扱う方法、あるいは今まで現実的ではなかった仕事です。

だからFineInTheoryでは、製品を選ぶ前に順番を一つ戻します。

Purpose → Means → Tool。

AI tools are multiplying faster than most reasons to use them.

日本語にすると少し身も蓋もありません。ツールは増えています。目的は、それほど頻繁には増えません。

1. まず、AIなしで終わるか

最初の質問は「どのAIがいいか」ではありません。

AIを使わずに終わる仕事か。

短い定型文を一度だけ直す。既に正しいExcel式がある。担当者へ確認すれば5分で終わる。そういう仕事なら、AIの比較を始める方が長くなることがあります。

ManualやHumanは失敗ではありません。

何も追加しないことも、正常な結論です。

2. 一つのGeneral AIで最後までできるか

AIが有効そうなら、まず一つのGeneral AIで仕事が終わるかを見ます。

ここでいうGeneral AIは、文章、質問、ファイル、分析など複数種類の知識作業を扱う広い作業面を持つAI製品、というFineInTheory上の分類です。

大事なのは「一番賢いモデル」を先に決めることではありません。

• 毎週やる仕事に使えるか
• 必要なファイルや情報へ届くか
• 出力をそのまま次の作業へ持っていけるか
• 既に使っている環境と無理なく接続できるか

を見る方が先です。

普通の文章作成、要約、ファイルを使った分析、日常的な調査なら、一つのGeneral AIだけで終わることがあります。

それで終わるなら、ここで止めます。

3. 追加契約の前に、Built-in specialistを確認する

General AIの中には、通常のチャットとは別に、調査など特定の仕事向けの機能が含まれています。

OpenAIはChatGPTにdeep researchを、AnthropicはClaudeにResearchを、GoogleはGemini AppsにDeep Researchを提供しています。細かな利用条件はプランや地域で変わるため、公開直前に再確認します。

ここでの判断は単純です。

今の契約の中に、足りないと思っていた機能が既にあるか。

あるなら、別のResearch AIへもう一つ課金する前に、まず含まれている機能でPurposeが終わるかを確認します。

「機能がある」と「専用製品と同等」は同じ意味ではありません。

ただし、存在を確認せずに追加契約する理由にもなりません。

4. 何が足りないのかを5種類に分ける

General AIやBuilt-in specialistで終わらなかったら、製品名を探す前に不足を言語化します。

Quality

出力そのものの品質が足りない。

例：音声、翻訳、特定形式の仕上がり。

Workflow

複数工程を毎回つなぐのが面倒。

例：会議→文字起こし→要点→担当者→記録。

Completion

素材ではなく完成物が必要。

例：スライド、動画、アプリ。

Context

毎回同じ資料や前提を入れ直している。

Capability

これまで手作業ではコストが合わず、そもそも現実的ではなかった仕事を可能にしたい。

不足がこのどれにも当てはまらないなら、追加ツールの理由はまだ弱いかもしれません。

5. External specialistを追加するのは、不足が明確なとき

専門AIは「General AIより上」という意味ではありません。

特定のPurposeで、追加コスト以上の差が出るなら使います。

例えば、通常の文章生成で十分なのに音声生成ツールを契約しても、文章はあまり音声になりません。逆に、自然な音声そのものが成果物なら、専門ツールには明確な役割があります。

判断基準はブランド数ではなく、追加した瞬間に何が改善するかです。

専門AI、本当に追加する必要があるかはP04で分けて考えます。

6. Coding AIは「同じチャットの強い版」ではない

コードを書く仕事では、Model名だけで選ぶと構造を見失いやすくなります。

現在はCodexやClaude CodeのようなCoding Agentがあり、一般的な会話画面とは別の開発Surfaceで、Repo、Files、Commands、Tests、Reviewなどを扱う方向へ製品が分かれています。

ここでは詳しく比較しません。

先に分けるのは、

• Modelが欲しいのか
• Agentへ仕事を委任したいのか
• IDEの中で流れを止めずに支援してほしいのか
• 完成したアプリが欲しいのか

です。

Coding AIの入口はP05で整理します。

7. Local / APIへ行く理由は「上級者だから」ではない

Local AIはCloud AIの上位版ではありません。

どこで動かす必要があるかというHosting decisionです。

例えば、

• データをCloudへ送れない
• Offlineが必要
• ModelやRuntimeを固定したい
• 一定量の処理を自分のInfrastructureで管理したい

といった制約があるならLocalやHybridが候補になります。

LM Studioのように、モデルを端末上で実行し、取得後はOffline operationも可能なLocal runtimeがあります。一方で「Local」という名前だけでPrivacyが完成するわけではありません。Application、Network、Logging、Model license、Updateも別に確認します。

APIも同じです。

チャット画面ではなく、自分のSoftwareから呼びたい。RoutingやControlが必要。そういう理由があるときに選びます。

単に設定項目を増やしたい場合は、設定項目だけが確実に増えます。

8. 今のあなたのDecision Map

文章、要約、普通の調査、ファイル分析

→ まずGeneral AI一つ。

深い調査を何度も行う

→ 今のGeneral AIにResearch機能が含まれているか確認。

特定の成果物やWorkflowだけ明確に弱い

→ External specialistを検討。

Repositoryを編集し、TestやCommandまで扱わせたい

→ Coding Agent / IDE route。

機密性、Offline、Hosting controlが本当の制約

→ Local / Hybridを検討。

Softwareへ組み込みたい

→ API / Router。

どれにも当てはまらない

→ 今あるものを使う。Free tierへ戻す。Humanで終わらせる。何も追加しない。

この最後の分岐は、かなり頻繁に正解です。

9. What would change our mind?

このDecision Mapは固定ではありません。

General AIに専門機能がさらに内包されれば、外部専門ツールが必要になる場面は減ります。

逆に、専門ツールがWorkflowやCompletionで明確な差を作れば、General AIだけで済ませる理由は弱くなります。

Local runtimeの運用負担が下がる、Cloud側のPrivacy条件が変わる、Coding AgentのSurfaceが統合される。そうした構造変化でも分岐は変わります。

そのためFineInTheoryでは、Model名より先にDecision structureを残します。

Model名は更新されます。Purposeは、もう少し長持ちします。