この1年で、何かが変わった
AI開発の現場にいると、2024年から2025年にかけて、空気が変わったのを肌で感じる。
以前は「どのベンダーに発注するか」が課題になっていることが多かった。今は「どうやって自分たちで作るか」が問われている。（と感じる。）
背景にあるのは、LLMの進化速度だ。Claude、Gemini、ChatGPT ——新しいモデルが数ヶ月ごとにリリースされ、開発現場では常に追いかけ続けなければならない。
受託開発では、モデルを切り替えるたびにベンダーとの交渉が発生し、週単位の遅延が生まれる。
一方、内製化の流れでは、その日のうちに最新モデルを試し、比較し、本番に反映できる。
この差が、2025年の競争優位を決める。そして、その答えとして開発トレンドに浮上してきたのが「ノーコードツールによる内製化」だと思う。
選挙で選ばれたノーコードツール
2025年10月、ある出来事が日本のAI開発の現場に静かな衝撃を与えたと考える。
高市早苗氏が自民党総裁選で展開した「AIサナエさん」。
わずか12日間の運用で7万件を超える質問に対応したこのシステムは、大がかりな開発チームが何ヶ月もかけて作ったものではない。（はずだ。）
採用されたプラットフォームは「Dify(ディフィ)」——ノーコードで構築できるAIエージェント開発ツールだ。
選挙という、最もセキュリティが求められる場面で、なぜオープンソースのノーコードツールが選ばれたのか？
ISO 27001/SOC 2 Type II等の国際セキュリティ認証を取得していること、短期間で立ち上げられること、そして外部ベンダーに依存せず内製化できること。この3つの理由が、政治の現場での採用を後押ししたのではないか。
同様に、2025年参議院選挙で安野たかひろ氏が展開した「AIあんの」も、前年のPythonサーバー実装からDify完全移行という戦略的判断を下している。理由は、時間的制約から、プログラミング不要でチームメンバーが理解・保守できるDifyを選択したのではないかと思う。
結果として、以下のようなAIあんのの実装を可能にして当選を果たした。
これは政治の世界だけの話ではない。日本を代表する企業が、同じ選択をしている。
内製化がもたらすもの
企業事例を見ると、内製化を選んだ組織には明確な成果が表れている。
具体例1：みずほ銀行の「Wiz Create」 みずほフィナンシャルグループは、社内で面談記録作成AIを開発。対面・オンライン会議の音声を自動で議事録にするこのツールにより、利用者の議事録作成時間が70%以上削減された。継続利用意向率は93%に達し、現場から高い評価を得ている。
初版は1カ月程度で構築し、正答率を計測しながら精度を改善するチューニングを実施できたのは、内製化による機敏性があったからだ。
具体例2：カカクコムのカスタマーサービス改革 価格.comを運営するカカクコムは、生成AI搭載のオペレーター支援ツール「KARAKURI assist」を導入し、月間450時間相当の業務時間削減を実現した。ナレッジ検索の精度向上と文面作成支援により、対応品質と効率が大幅に改善している。
内製化の本質的な価値
数字以上に重要なのは「自律性」だと考える。みずほはAWS上に開発基盤「Wiz Base」を整備し、約15人のエンジニアで複数のAIモデルを柔軟に切り替えられる構成を実現した。
外部ベンダーに依存せず、自分たちでモデルを選び、プロンプトを調整し、ワークフローを改善できる。市場が変化したとき、競合が新しい手法を導入したとき、即座に対応できる組織と、ベンダーの対応を待つ組織——この差は、時間とともに開いていくのではないか。
成功の鍵は「ユースケース設計」か
ここで冷静になろう。
McKinseyの2025年調査によれば、78%の企業がGen AIを導入している一方で、80%以上が収益への実質的な貢献を報告していない。
さらにMITの調査では、企業のAI試験導入プロジェクトの約95%が失敗している。
理由は明確で、コストの高騰、ビジネス価値の不明確さ、不十分なリスク・コントロール—そして何より、実運用での改善サイクルを回せていないことが原因ではないだろうか。
電通総研のAIエンジニア・太田真人氏は「2025年はユースケースを血眼で探す年」と指摘している。
RAGによる業務効率化の限界が見え、AIエージェントに目が向き始めた——しかし、何に使うかが定まっていない企業は失敗する。
成功企業の共通点：明確なユースケース設計
- みずほ銀行は「会議記録」という1つのユースケースに絞り込んだ。AWS上に構築した面談記録作成AI「Wiz Create」で、作成時間を70%以上削減し、継続利用意向率93%を獲得している。
- カカクコムは、Difyエンタープライズ版を全社的なAI活用プラットフォームとして導入した。カスタマーサービス部門では生成AI搭載の「KARAKURI assist」により月間450時間の業務削減を実現。現場主導でAI活用を推進している。
- 東京海上日動は「中小企業向け営業支援」をターゲットにした。AIで顧客との会話を分析し、100種類以上の保険商品から最適な提案を行うシステム「マーケットインナビ」を約半年で内製開発。経験の浅いスタッフがベテランレベルのパフォーマンスを発揮できるようになった。
3社に共通するのは、最初から広範囲を狙わず、具体的な業務課題に絞り込んでいる点に思える。
「全社的なDX」ではなく、「この業務のこの部分」という明確なスコープ設定が、内製化による迅速な価値実現を可能にしている。「小さく始めて、明確な成果を出す」これが内製化成功の鉄則なのではないか。
ユースケース設計から実装へ：現場主導のPDCAを回す環境づくり
ユースケースを明確に定めた後、次の課題は「どう実装し、どう改善サイクルを回すか」だ。
なぜノーコード・ローコードツールなのか
前述の成功企業—みずほ銀行、カカクコム、東京海上日動—に共通するもう一つの特徴がある。それは現場が主導権を持ち、迅速にPDCAを回している点だ。営業担当者のフィードバックを即座に反映したり、半年という短期間で内製開発を完了させたりしている。
従来の開発プロセス（要件定義→設計→開発→テスト→デプロイ）では、現場のフィードバックを反映するのに数ヶ月かかる。しかし、AIエージェントはプロンプトやワークフローの微調整で劇的に精度が変わる。
多くのプロジェクトが中止される理由は、初期設計で完璧を目指しすぎて、実運用での改善サイクルを回せないことにある。成功の鍵は、改善サイクルを週単位、場合によっては日単位で回すことだ。
そのために必要なのが、技術的ハードルが低く、変更を即座にテスト・デプロイでき、かつ本番環境で実運用に耐えるツールだ。この条件を満たすのが、ノーコード・ローコードのAIエージェント開発ツールだと考える。
現場が選ぶ2つの選択肢
- Dify：対話型AI開発プラットフォーム
- Difyは、チャット・RAG（検索拡張生成）に最適化された設計で、視覚的ワークフローエディターにより非技術系メンバーでもAIアプリケーションを構築できる。
- 営業担当者や業務部門が直接プロンプトを調整でき、変更から検証までが数時間で完結する。高市早苗氏の「AIサナエさん」は総裁選で7万件超の質問に対応し、カカクコムでは年間18,000時間の削減効果を達成した。
- n8n：ワークフロー自動化エンジン
- n8nは、422以上の外部サービス連携が強みで、JavaScriptベースのカスタムコードにも対応する。
- CRM・ERP・SaaSツールとの連携を素早く構築し、条件分岐やエラーハンドリングを視覚的に設計できる。2025年、シリーズBで6,000万ドルを調達し、企業評価額は2億7,000万ドルに達した。
- 複数システムを跨ぐ業務プロセスの自動化に向いている。
ビッグテックの参入：2025年の転換点
2025年は、ノーコード・ローコードでのAIエージェント構築が「実験」から「標準」へ移行した年だと感じる。
- Microsoftは2025年10月、Azure AI Foundryで「Microsoft Agent Framework」（パブリックプレビュー）を発表。AutoGenとSemantic Kernelを統合し、マルチエージェントシステムの構築を簡素化した。
- GoogleもVertex AI Agent Builderで、Google Cloudインフラとの統合を武器にエンタープライズ市場に参入している。
- OpenAIは2025年3月に「Responses API」とエージェント構築用ツールセットをリリースし、さらに10月のDevDayでは、ドラッグ&ドロップ型の「Agent Builder」を発表予定との情報が流れている。
これらの動きは、「現場主導でPDCAを回せるツール」が企業AI戦略の中核になったことを物語っており、オープンソースのDify・n8nが先行して市場を開拓し、その後を追う形でビッグテックが本格参入してきた構図に見える。
パーツ交換型アーキテクチャ：LLM進化に振り落とされない設計
これらのノーコードツールに共通するのは、LLMプロバイダーをパーツとして扱う「モジュラーアーキテクチャ」だ。以下、DifyとN8nを例に見ていこう。
Difyの例：Model Runtimeによる抽象化
Difyはv0.4.0で導入した「Beehiveアーキテクチャ」により、各コンポーネントが独立しながら協調動作する設計を実現した。
v0.4.0以前から数百の商用・オープンソースモデル（LLM、Text Embedding、Rerank、Speech2Text、TTSなど）をサポートしており、商用モデル（OpenAI、Anthropic、Google）、オープンソースモデル（Llama、Hugging Face）、ローカルデプロイ（Ollama、OpenAI互換API）、Azure OpenAI、MaaSベースモデルまで、統一インターフェースで利用できる。
視覚的ワークフローエディターでは、ワークフローの各ノードに異なるモデルを割り当てられる。例えば、内部処理にコスト効率の良いGPT-3.5-Turboを使い、顧客向け応答に高品質なGPT-4oを使うといった、ワークフロー段階に応じたシームレスな切り替えが可能だ。
n8nの例：ノードベース設計
n8nは各AI機能を交換可能なノードとして扱い、422以上の外部サービス連携をサポートする。
AI Agentノード（OpenAI、Anthropic、Google、Groq、Azureサポート）、LangChain統合ノード、カスタムLLM API用HTTPリクエストノードが用意されている。n8nのモジュラーな性質により、新しいモデルがリリースされるとすぐにサポートでき、アップグレードや再起動なしで利用可能になる。
このパターンにより、同じワークフロー内で異なるタスクに異なるAIモデルを使用できる——一つのモデルでテキスト生成、別のモデルで画像作成、さらに別のモデルでデータ分析が可能だ。
この設計により、GPT-4からClaude 4、Gemini 2.5へ——モデルが進化しても、アプリケーション全体を再構築する必要がない。設定を変えるだけだ。
なぜパーツ交換型が重要なのか
AIモデルの進化サイクルを見てみよう
2024年3月から2025年9月まで、わずか18ヶ月で主要3社（Anthropic、OpenAI、Google）から計15以上のメジャーアップデートがリリースされている。
平均すると約5〜6週間ごとに新しいモデルが登場している計算だ。
受託開発では、モデル切り替えのたびにベンダーとの交渉、見積もり作成、契約締結、実装・テストというプロセスが発生する。合計で数週間から数ヶ月かかる。その間に、競合は次のモデルに移っている。
ノーコードツールでは、ドロップダウンメニューから選択し、プロンプトを調整し、テストして本番反映する。数時間から1日で完了する。この差が、2026年の競争優位を決めるのではないだろうか。
どう始めるか：組織の現状を見極める
AI導入を始める前に、まず自社の立ち位置を理解することが重要だ。
日本銀行の金融機関調査（2024年）は、クラウドサービス利用について組織を4つのグループに分類している。この分類は、個人的にAI導入の戦略を考える上でも示唆に富むと思う。
組織の4つのグループ分類
グループ①は、現在利用中で今後拡大予定の組織だ。重要領域でのクラウド利用を展望し、可用性を重視している。主な課題は利用拡大に伴うコスト管理となっている。
グループ②は、現在利用中だが拡大予定なしの組織だ。機密性・セキュリティに関するモニタリングなど初期課題への意識が後退し、現状維持とコスト最適化に焦点が移っている。
グループ③は、現在未利用だが今後利用開始予定の組織だ。自組織の体制確立・整備のほか、インシデント発生時の体制確立が課題となっており、監督当局の方針といった拡大時課題への懸念を抱えている。
グループ④は、現在未利用で今後も利用予定なしの組織だ。体制確立・整備のほか、機密性・セキュリティに関するモニタリング、クラウド事業者の統制が課題となっている。このグループは最もリテラシーギャップが大きく、基盤整備が不十分なケースが多い。
グループ④の組織が取るべきアプローチ
もしあなたの組織がグループ④に該当する場合、いきなりAIを重要領域に導入することは失敗リスクが高い。多くの場合、現行システムへのアクセス権の管理やクラウド事業者への統制が不十分といった、そもそもの基盤が整っていない。この状況下でいきなりAIを重要領域に直接導入しようとすると、リテラシーのギャップにより失敗する可能性が高い。
推奨されるのは段階的なアプローチだ。まず基盤整備を行い、次に非重要領域でAIの試験的導入を行って実際に使用してもらう。そこで段階的にリテラシーギャップを解消しながら、最終的に本来の目的である重要領域への導入を検討する。地道ではあるが、この順序を踏むことで組織全体のAIリテラシーを底上げしながら、確実に成果を積み上げていくことができる。
実装の4つのステップ
ステップ1：ユースケースを絞る
「AIで業務効率化」ではなく「会議議事録の自動作成」。「カスタマーサポート強化」ではなく「FAQ対応の24時間自動化」。明確で測定可能なユースケースを1つ選ぶ。
重要なのは、組織の成熟度に応じた領域選定だ。グループ③・④の組織は、まず非重要領域から始めるべきだ。失敗しても大きな影響がない領域で学びを得て、成功パターンを確立してから重要度の高い業務に展開する。具体的には、社内向けFAQボット（顧客向けではなく）、社内会議の議事録作成（外部公開資料ではなく）、社内データの検索・要約（機密度の低い情報から）といったユースケースが適している。
一方、グループ①・②の組織は、すでにクラウド基盤が整っているため、より早く顧客接点のある業務に展開できる。
成功事例から学べることは多い。みずほ銀行は「面談記録作成」という社内業務から開始し、作成時間70%以上削減を達成した。カカクコムは「カスタマーサービス部門の問い合わせ対応」で月間450時間削減を実現した。東京海上日動は「中小企業向け営業支援」で約半年で内製開発を完了させた。3社に共通するのは、最初から広範囲を狙わず、具体的な業務課題に絞り込んでいる点だ。
ステップ2：小さく始める（PoC）
期間は2〜4週間、テストユーザーは10〜50人、予算は数十万円から始める。成功基準は、タスク完了率とユーザーからのポジティブフィードバックだ。
完璧を目指さず、学びを得ることを優先する。MIT調査では95%の企業のAI試験導入プロジェクトが失敗しているが、その多くは「完璧な設計」を目指して実運用での改善サイクルを回せなかったことが原因だろう。
ステップ3：プラットフォームを選ぶ
チャット・RAGならDify、業務自動化ならn8n、エンタープライズならMicrosoft Agent FrameworkやVertex AI Agent Builderを検討しよう。まずは無料版やコミュニティ版で試し、感触を掴む。パーツ交換型アーキテクチャにより、モデルの進化に柔軟に対応できる設計を選ぶことが重要だ。
ステップ4：測定し、学び、スケールする
効率向上を数値で確認する。作業時間の削減率、エラー率の改善、ユーザー満足度を測定し、ROIを明確化する。成果が出たら次のユースケースに展開し、失敗したら原因を分析して別のアプローチを試す。
行動しないリスク
「様子を見よう」と思っているなら、考え直してほしい。
McKinsey調査によれば、78%の企業がGen AIを導入している一方で、80%以上が収益への実質的な貢献を報告していない。MIT調査では、企業のAI試験導入プロジェクトの約95%が失敗している。
しかし、これは「AI導入が無意味」という意味ではない。失敗の原因は明確だ：
- コストの高騰
- ビジネス価値の不明確さ
- 実運用での改善サイクルを回せていないこと
- ベンダー依存による遅延
競合がAI優位性を構築している間に、取り残される組織は急速に競争力を失う。
LLMは平均5〜6週間ごとに進化している。受託開発では、モデル切り替えのたびに週単位の遅延が発生する。内製化した組織は、その日のうちに最新モデルを試し、本番に反映できる。
この差が、2026年の競争優位を決める。
Build, Don’t Buy.
内製化は、単なるコスト削減ではない。
組織の自律性を取り戻し、LLM進化の波に乗るための戦略的投資だ。みずほ銀行、カカクコム、東京海上日動——成功企業に共通するのは、外部ベンダーに依存せず、自分たちでモデルを選び、プロンプトを調整し、ワークフローを改善できる体制を構築したことだと思う。
2025年は「実験」から「実装」へ移行した年だ。
2026年は、実装から「競争優位の確立」へ移行する年になる。
今日から始めよう。小さく始めて、明確な成果を出す。それが、AI時代を生き抜く組織への第一歩だ。
Views: 0
