ローコードプラットフォームの黄昏：なぜClaude Agent SDKがDifyを歴史にするのか

「最高のツールとは、人間の思考に沿ったツールである。」 — Difyから脱出した開発者

I. 冒頭のシーン：あなたならどうタスクを与えますか？

あなたがレストランのオーナーで、新入社員に顧客からのクレーム対応を教える必要があるとします。どうしますか？

方法A：フローチャートを描く

[開始] → [顧客の話を聞く] → [料理が冷めている？]
           ↓ はい                  ↓ いいえ
      [温め直す] → [謝罪] → [サービスが遅い？]
                               ↓ はい      ↓ いいえ
                           [無料の料理] → [態度の問題？]
                                          ↓ はい    ↓ いいえ
                                      [担当者変更] → [...]

そして従業員に言います：「このフローチャート通りに正確に従ってください。どのノードも間違えないように。」

方法B：直接言う

「クレーム対応は簡単だよ。まず何が問題か聞いて。料理が冷めていたら温め直す。サービスが遅かったら無料の料理を出して謝る。態度の問題なら別の人に対応してもらう。要するに、お客様を満足させればいい。具体的な状況は自分で判断して。」

どちらを選びますか？

99%の人は方法Bを選ぶでしょう。

なぜなら人類は何千年もこうやって知識を伝えてきたからです：言語で意図と原則を説明し、相手に理解させて柔軟に実行させる。

弟子に何かを教えるのに100ノードのフローチャートを描く人はいません。

しかし皮肉なことに、AIを使い始めたとき、業界全体が方法Aを選んでしまいました。

これがDifyをはじめとするローコードプラットフォームの根本的な問題です。

II. LLMの第一原理：言語知能であり、フローチャート実行機ではない

第一原理から考えましょう：大規模言語モデルとは何でしょうか？

LLMの本質は：自然言語を理解し生成する知的エージェントです。

何兆もの自然言語テキストで訓練されている
人間の意図、文脈、暗黙のロジックを理解する
核心能力は言語理解と推論

これは何を意味するのでしょうか？

LLMは生まれながらにして「人間の言葉」を理解するということです。

「顧客のクレームに対応する」と言えば、それが何を意味するか理解します。「料理が冷めていたら温め直す」と言えば、そのロジックを理解します。「お客様を満足させる」と言えば、その目標を理解します。

これをフローチャートに変換する必要はありません。

中国語を話す人にタスクを与えるとき、まず英語に翻訳し、次にフローチャートに変換し、それから実行させる人はいないでしょう。

直接中国語で話せばいいのです。

III. 人間の原始的行動パターン：自然言語によるプロセス伝達

人類は何千年もの間、どのように作業プロセスを伝えてきたのでしょうか？

師匠が弟子に教える

「弟子よ、木工はこうやる：まず寸法を測り、線を引き、鋸で線に沿って切り、最後に滑らかに磨く。切るときは安定させて、曲がらないように。」

フローチャートもノードもなく、自然言語の説明だけです。

教師が生徒に教える

「作文には導入、本文、結論が必要です。導入は読者を引きつけ、本文は論理的で、結論はテーマに戻ります。具体的な書き方はテーマ次第です。」

固定テンプレートはなく、原則と例示だけです。

上司が仕事を指示する

「あの顧客のクレームに対応してきて。まず状況を理解して、払うべきなら払い、謝るべきなら謝る。とにかく事を荒立てないで。」

SOPドキュメントはなく（現代の大企業にはありますが、それは別の話です）、目標と方向性だけです。

これが人間の原始的行動パターンです：自然言語で意図、原則、プロセスを説明し、実行者に理解させて柔軟に処理させる。

なぜ自然言語がより自然なのか？

自然言語には他の方法では代替できないいくつかの利点があります：

文脈を保持：「払うべきなら払う」は「合理的な範囲内で」を含意
柔軟性を許容：「自分で判断して」は実行の余地を与える
意図を伝達：ステップだけでなく「なぜそうするのか」も
理解しやすい：誰でも理解でき、特殊な言語を学ぶ必要がない

フローチャートはいつ登場したのでしょうか？

産業革命の後です。

なぜでしょうか？機械は人間の言葉を理解せず、固定命令しか実行できないからです。

だから私たちはフローチャート、SOP、標準作業を発明しました—人間の柔軟性を取り除き、プロセスを機械化しました。

しかしLLMは機械ではなく、知的エージェントです。

人間の言葉を理解するのに、なぜ産業時代のフローチャートで制約するのでしょうか？

IV. Difyの本質的問題：グラフィックで言語知能と戦う

今、私たちは理解しました：

LLMは言語知能である
人間は自然言語でプロセスを伝達する

ではDifyは何をしているのでしょうか？

Difyは自然言語の意図をグラフィカルなノードと接続に翻訳することを要求します。

例えば：

あなたの元の意図（自然言語）：

「注文クレームに対応：まず注文情報を確認し、クレームタイプを分析し、遅延問題なら補償を計算して返金し、品質問題ならサプライヤーに連絡し、最後に処理を記録する。」

Difyでは、以下が必要です：

「データベースクエリ」ノードをドラッグし、クエリパラメータを設定
「AI分析」ノードをドラッグし、プロンプトを設定
「条件判断」ノードをドラッグし、判断ルールを設定
遅延問題と品質問題を処理する2つのブランチをドラッグ
各ブランチにさらに3-5個のノードをドラッグ
すべてのノード間の接続と変数渡しを設定
テスト、デバッグ、修正、再テスト...

最終的に20ノードのフローチャートができあがります。

何が問題なのでしょうか？

翻訳コストの追加：自然言語 → グラフィカルノード（完全に不要）
文脈の喪失：ノードは「何をするか」しか表現できず、「なぜ」を表現しにくい
柔軟性の制限：すべてのブランチを事前設計する必要があり、AIが柔軟に決定できない
保守の悪夢：ノードが増えると、一つ変更するだけで10の接続を確認する必要がある

さらに重要なことに：これはLLMの核心能力と完全に対立しています。

LLMは自然言語で記述されたプロセスを自然に理解します。それなのにグラフィカルな抽象化を理解することを強制されます。

これは中国語を話す人にタスクを与えるのに、まず中国語を火星語に翻訳してから実行させるようなものです。

なぜ余計な手順を踏むのでしょうか？

V. Skillの本質：自然言語でプロセスを記述する

では、Claude Agent SDKのSkillがどのように機能するか見てみましょう。

Skill = 1つの.mdファイル

そうです、ただの普通のMarkdownファイルです。

handle-order-complaint.skill.md：

# 注文クレーム対応プロセス

## 目標
顧客の注文クレームを適切に処理し、顧客満足を確保し、プロセスを記録する。

## 利用可能なツール（MCP）
- database.query: 注文情報を照会
- ai.analyze_sentiment: クレームタイプを分析
- payment.calculate_compensation: 補償額を計算
- payment.apply_refund: 返金を実行
- supplier.contact: サプライヤーに連絡
- logging.log_event: イベントを記録

## プロセス
注文クレームを受け取ったとき：

1. database.queryを使用して詳細な注文情報を取得
2. ai.analyze_sentimentを使用してクレームタイプを分析（遅延、品質、サービスなど）
3. クレームタイプに基づいて適切な行動を取る：
   - 遅延問題の場合：
     - payment.calculate_compensationを使用して補償額を計算
     - payment.apply_refundを使用して返金を実行
     - 顧客に謝罪し、補償プランを説明
   - 品質問題の場合：
     - payment.calculate_refundを使用して返金額を計算
     - payment.apply_refundを使用して返金を実行
     - supplier.contactを使用してサプライヤーに問題を報告
   - サービス態度の問題の場合：
     - 顧客に謝罪
     - 顧客がまだ不満なら、人間のサポートに転送
4. logging.log_eventを使用してプロセス全体を記録（コンプライアンスのため）
5. 解決策をまとめて顧客に通知

## 注意事項
- 常に礼儀と共感を保つ
- 補償は合理的で、注文額の50%を超えてはならない
- 重大なクレーム（1000ドル超）は上級サポートにエスカレートする必要がある
- すべての操作はコンプライアンスのためにログに記録する必要がある

これだけです。

これがDifyで20ノードが必要なプロセスです。

しかしここには自然言語の説明だけがあります。

SkillはサブSkillとMCPツールをスケジュールできる

Skillは孤立していません。以下が可能です：

MCPツールをスケジュール（原子能力）
- database.query：データベースクエリ
- payment.apply_refund：支払いインターフェース
- logging.log_event：ログ記録

他のSkillをスケジュール（サブプロセス）

# 注文クレーム対応プロセス（メインプロセス）

クレーム額が1000ドルを超える場合：
- escalate-to-senior.skillを呼び出す（上級サポートにエスカレート）

補償を計算する必要がある場合：
- calculate-compensation.skillを呼び出す（補償額を計算）

関数呼び出しのように自然です。

メインSkillは全体プロセスを説明し、サブSkillは具体的なステップを処理し、MCPツールは原子能力を提供します。

明確な階層、柔軟な構成。

AIは自然言語を理解し、インテリジェントに実行する

顧客が「注文が3日経っても発送されない」とクレームしたとき：

AIはSkill.mdファイルを読み、以下を理解します：

これは注文クレームシナリオで、handle-order-complaint.skillを使用すべき
まず注文情報を確認（database.queryを呼び出す）
クレームタイプを分析（ai.analyze_sentimentを呼び出す）、「遅延問題」と判断
遅延問題のプロセスに従う：補償を計算、返金を実行
イベントを記録（logging.log_eventを呼び出す）
顧客に通知

AI自身が決定し、柔軟に実行します。フローチャートは不要です。

比較：Dify vs Skill

次元	Dify Workflow	Skill.md
記述方法	グラフィカルノード+接続	自然言語Markdown
作成方法	ドラッグ、設定、接続	.mdファイルを書く
保守難易度	ノードが多いと理解困難	一目瞭然
柔軟性	固定パス	AI柔軟決定
学習曲線	プラットフォーム固有概念を学ぶ	自然言語、障壁ゼロ
移植性	プラットフォーム固有	プレーンテキスト、どこでも動く
人間の思考に合致	❌	✅
AI能力に合致	❌	✅

VI. なぜこれが本質的な違いでありパラダイムシフトなのか？

1. 人間の原始的行動パターンへの回帰

何千年もの間、人類は自然言語でプロセスを伝達してきました。

Difyはグラフィカルにプロセスを記述することを要求します（産業時代の産物）。

Skillは自然言語に戻ることを可能にします（人間の原始パターン）。

これは技術的後退ではなく、概念的進歩です。

2. LLMの核心能力を解放する

LLMは言語知能であり、フローチャート実行機ではありません。

DifyはLLMの能力を制限します（固定パスしか実行できない）。

SkillはLLMの能力を解放します（意図を理解し、柔軟に決定）。

これがAIの正しい使い方です。

3. 真の障壁を下げる

Difyはプログラミング障壁を下げると言いますが、新しい障壁を作ります：グラフィカルオーケストレーションを学ぶこと。

Skillは真に障壁を下げます：人間の言葉で何が欲しいか説明するだけです。

プログラミングを学ぶ必要も、プラットフォームを学ぶ必要も、新しい概念を学ぶ必要もありません。

話せれば、Skillが使えます。

4. 第一原理に合致

Difyの論理：

プログラミングは難しい → グラフィックで障壁を下げる → 新しい複雑さを作る → 急な学習曲線

Skillの論理：

プログラミングは難しい → AIに人間の言葉を理解させる → 自然言語でプロセスを記述 → 学習曲線ゼロ

どちらがより第一原理に合致しますか？

5. パラダイムシフト

旧パラダイム（Dify）：人間が機械に適応

自然言語の意図をグラフィカルプロセスに翻訳
柔軟なロジックをノード接続に固化
人間の思考を機械が理解できる形に成形

新パラダイム（Skill）：機械が人間に適応

AIが直接自然言語の説明を理解
AIが文脈に基づいて柔軟に決定
人間が最も自然な方法で意図を表現

これがAI時代の本質です：人間を機械のようにするのではなく、機械を人間を理解するようにすること。

VII. Workflowの複雑性の罠

「ビジネスが複雑だからWorkflowが必要だ」と言う人がまだいます。

Difyで「複雑なビジネス」がどう見えるか見てみましょう：

実際のeコマースカスタマーサービスWorkflow：

147ノード
89接続線
20以上の顧客意図を処理
意図ごとに3-5のブランチ
さらにエラー処理、ログ記録、コンプライアンス、A/Bテスト...

このWorkflowを保守する体験：

1つのノードを変更すると10の接続を確認
1つの機能を追加するのに2日間テスト
新入社員が3日間見ても理解できない
マインスイーパーをプレイしているよう

Skillを使ったら？

メインSkill（全体プロセス）：

# eコマースカスタマーサービスプロセス

顧客が問い合わせたとき：
1. 顧客の意図を理解
2. 意図に基づいて対応するサブSkillを呼び出す：
   - 価格問い合わせ → price-inquiry.skill
   - 注文状況 → order-status.skill
   - クレーム対応 → handle-complaint.skill
   - 返金リクエスト → process-refund.skill
   - ...
3. 会話をログに記録
4. 顧客の問題が未解決なら、人間にエスカレート

サブSkill（具体的プロセス）：

# handle-complaint.skill
クレーム対応の詳細ステップ...

# order-status.skill
注文状況確認の詳細ステップ...

各Skillはシンプルで明確、組み合わせて複雑なビジネスを処理します。

これが関数型プログラミングの思想です：複雑な問題をシンプルなモジュールに分解する。

VIII. MCPプロトコル：標準化された原子能力

もう一つの重要なポイント：MCP (Model Context Protocol)。

MCPツール = 標準化された原子能力

# Skillが呼び出せるMCPツール

## データベース操作
- database.query: データを照会
- database.insert: データを挿入

## ファイル操作
- filesystem.read: ファイルを読む
- filesystem.write: ファイルを書く

## サードパーティ統合
- slack.send_message: メッセージを送信
- email.send: メールを送信
- payment.process: 支払いを処理

Skillは自然言語でこれらのMCPツールをどう組み合わせるか記述します。

AIはこれらの説明を理解し、適切なツールをインテリジェントに呼び出します。

これは次のようなものです：

MCPツールは「LEGOブロック」（標準化コンポーネント）
Skillは「組み立て説明書」（自然言語で組み合わせ方を記述）
AIは「賢い建設者」（説明書を理解し、柔軟に構築）

IX. Difyユーザーへのアドバイス

まだDifyを使っているなら、すぐに放棄しろとは言いません。

しかし考えてみてください：

プロセスを記述していますか、それともフローチャートを描いていますか？
- 前者なら、Skillの方が適しているかも
- 後者なら、「なぜ描くのか」自問してください
Workflowにいくつノードがありますか？
- 10未満：まだ保守可能
- 10-50：痛み始める
- 50以上：Skillsへのリファクタリングを検討
開発とデバッグ、どちらに時間を使っていますか？
- デバッグなら、ツールの問題かもしれません、あなたの問題ではなく
プロセスを自然言語で記述してみてください
- 明確に記述できるなら、グラフィックは不要
- 明確に記述できないなら、描いても助けにならない

X. 結論：自然への回帰こそが未来

人類は何千年も自然言語で知識とプロセスを伝達してきました。

産業革命がフローチャートを発明したのは、機械が人間の言葉を理解しないからです。

AI時代、LLMは人間の言葉を理解します。

なぜまだフローチャートを使うのでしょうか？

Claude Agent SDKのSkillメカニズムは、最も自然な方法に私たちを戻します：

自然言語で何が欲しいか記述し、AIが理解してインテリジェントに実行する。

プログラミングを学ぶ必要も、プラットフォームを学ぶ必要も、フローチャートを描く必要もありません。

話せれば、Agentを構築できます。

これは技術的後退ではなく、人間の原始的行動パターンへの回帰です。

これはツールのアップグレードではなく、パラダイムシフトです。

「人間が機械に適応する」から「機械が人間を理解する」へ。

これがAI時代のあるべき姿です。

あなたはどう思いますか？コメント欄で考えを共有してください。

Difyの147ノード構成を学ぶべきかまだ悩んでいるなら、私のアドバイスは：

悩まないで。.mdファイルを書き、人間の言葉で欲しいものを記述し、残りはAIに任せてください。