9.6.8 ローコードプラットフォーム【選択】
すべてのチームが次のことをしたいわけではありません。
- 状態機械を手書きする
- ツール登録を手書きする
- スケジューリングロジックを手書きする
多くのチームが本当に欲しいのは、次のことです。
まず流れを組み立てて、みんなが見て分かるようにすること。
ローコードプラットフォームの核心的な価値は、まさにここにあります。
学習目標
- ローコードプラットフォームがなぜAgentの場面で流行しやすいのかを理解する
- どのような形のタスクに最も向いているかを理解する
- コードベースのフレームワークと比べたときの、本当の強みと代償を理解する
- いつローコードを使い、いつコードに戻るべきかの判断基準を持つ
ローコードプラットフォームの最も核心的な価値は何ですか？
これは「エンジニアを置き換える」ためではない
より正確に言うと、通常は次のことをしています。
- 試作を始めるハードルを下げる
- エンジニア以外のメンバーも流れの議論に参加できるようにする
- ワークフローを見やすくし、変更しやすくする
なので、本当の価値は次ではありません。
「コードを書かなくていい」。
そうではなく、次のことです。
「流れの表現と協力を、もっと軽くする」。
たとえで言うと
ローコードプラットフォームは、まるで次のようなものです。
- システムの流れをソースコードからフローボードに変える
もちろん、ボードだけで全てのエンジニアリング詳細を置き換えることはできません。
でも、とても向いているのは次のようなことです。
- すばやく試す
- すばやく変える
- すばやく議論する
なぜAgentの場面では特にローコードが出てきやすいのですか？
それは、多くのAgentシステムがもともと次のような形をしているからです。
- 入力
- 判断
- ツールを呼び出す
- 検索する
- 返答する
このような「ノード + フロー」の構造は、いったん可視化すると、次の人たちが一緒に議論しやすくなります。
- プロダクト
- 運用
- 分析
- エンジニアリング
つまり、Agentシステムそのものが、ワークフローとして表現しやすいのです。
最小のワークフローのイメージ
workflow = {
"trigger": "user_message",
"steps": [
"classify_intent",
"retrieve_docs",
"generate_answer"
]
}
print(workflow)
想定出力：
{'trigger': 'user_message', 'steps': ['classify_intent', 'retrieve_docs', 'generate_answer']}
この例は何を本当に表していますか？
これは、ローコード思考の核心を表しています。
まずシステムを、たくさんのばらばらなコードではなく、いくつかのノードと接続関係として見ること。
だからこそ、ローコードプラットフォームは試作にとても向いていることが多いのです。
ローコードプラットフォームはどんなタイプのタスクに向いていますか？
特に向いている
- FAQ ワークフロー
- 承認フロー
- 検索Q&Aの試作
- シンプルなコンテンツ生成チェーン
これらには、たいてい次の特徴があります。
- 流れがはっきりしている
- ノードごとの役割が明確
- 変更頻度が高い
必ずしも向いていない
もしあなたのシステムに次のものが必要なら、
- 複雑な状態機械
- 大量のカスタムロジック
- 高度に最適化された下層制御
ローコードプラットフォームでは、だんだん足りなくなるかもしれません。
ローコードプラットフォームの最大の強みはどこにありますか？
可視化によるコミュニケーション
多くの場合、「他の人に流れを理解してもらえるか」自体が、大きな価値です。
試作スピード
特に次の段階で価値があります。
- 要件検証
- 方案の試運転
- 役割をまたいだ協力
流れ変更コストを下げる
ビジネスロジックが頻繁に変わるなら、
ローコードのワークフローは、いくつかの処理をハードコードするより柔軟なことがあります。
でも、なぜローコードは過大評価されやすいのでしょうか？
複雑さを自動で消してくれるわけではない
流れが本当に複雑になると、可視化された図もどんどん見づらくなることがあります。
多くの「ローコードシステム」は、最後にはコードに戻る必要がある
例えば次のようなものです。
- カスタムツール
- 特殊な状態ロジック
- 複雑な権限制御
つまり、ローコードは次のようなものに近いです。
まずシステムを素早く立ち上げるための方法。
すべてのシステムの最終形ではありません。
とても重要な問題：誰がこのプラットフォームを使うのですか？
主にエンジニアチームだけが使うなら
多くの場合、直接コードフレームワークを使っても問題ありません。
次の役割も一緒に参加してほしいなら
- プロダクト
- 運用
- 分析
ローコードの価値は、かなり上がります。なぜなら、
- 一緒に議論しやすい
- 流れの合意を作りやすい
だからです。
つまり、ローコードプラットフォームは多くの場合、単なる技術判断ではなく、協力の判断でもあります。
いつローコードからコードへ戻るべきですか？
これは、だいたい次のようなときに起こります。
- ノード図がどんどん複雑になる
- カスタムロジックが増える
- デバッグがつらくなる
- バージョン管理がどんどん難しくなる
このときは、たいてい次のことを意味します。
あなたのシステムはもう「可視的な試作」から「エンジニアリングシステム」段階に入っている。
つまり、ローコードはたいてい次に向いています。
- 0 から 1
しかし、必ずしも次には向いていません。
- 1 から 100
初心者がよく踏む落とし穴
ローコードは見た目が速いから、何でもそれで作ってしまう
これは、複雑さが増えたあとに壁にぶつかることが多いです。
立ち上げ速度だけを見て、長期保守を見ない
これが、ローコードが最も過大評価されやすいところです。
ローコードならシステム理解が不要だと思ってしまう
実際はその逆です。
システム原理を理解していなければ、問題を可視化画面の中に隠しているだけです。
まとめ
この節で一番大事なのは、「ローコードが良いか悪いか」を判断することではなく、次を理解することです。
ローコードプラットフォームは、流れが明確で、すばやく試したくて、複数人で一緒に理解する必要があるAgentの場面に、特に向いている。
これはとても価値のあるツールの一種ですが、すべてのシステムのゴールだと考えるべきではありません。
練習
- 自分のAgentの流れを1つ考えて、ノード式で表すのに向いているか判断してみましょう。
- 自分の言葉で説明してみましょう：なぜローコードは要件検証の段階に特に向いているのですか？
- 考えてみましょう：「ローコードは実装のハードルは下げられるが、理解のハードルは置き換えられない」と言えるのはなぜですか？
- もしあなたのシステムに状態のループが多いなら、それでもローコードプラットフォームを最優先で選びますか？なぜですか？