WEBVTT

00:00:00.000 --> 00:00:08.000
あなたのローコード自動化が機能しないのは賢くなりすぎているからです 現実世界の乱雑で矛盾したデータに直面しシステムが毎日クラッシュする状況では

00:00:08.000 --> 00:00:13.240
厳格なイフゼン論理は致命的です データはクリーンであるという前提こそがローコード設計における現在です

00:00:13.240 --> 00:00:19.720
私たちはイフゼンモデルの上に世界を築きましたがそのモデルが機能するには絶対的な 確実性が必要なのです現実世界のデータに確実性はありません

00:00:19.720 --> 00:00:27.780
タイプミスがあります文脈が欠落しています それは人為的ミスによる混沌とした流れです決定論的システムは1%の変動に直面すると

00:00:27.780 --> 00:00:35.360
しなることも適用することもできません ただ壊れるだけですこれが脆さの罠を生み出し自動化の強度は最も綺麗なデータポイントに依存することになります

00:00:35.360 --> 00:00:41.820
企業においてそれは成功の基準としてあまりに低すぎます しかし問題はデータではなくそれを処理するために使用しているモデルにあります

00:00:41.820 --> 00:00:48.960
決定論の終焉です決定論的論理は構造化データ時代の異物です すべてがSQLテーブルに収まり

00:00:48.960 --> 00:00:57.660
人間を定義済みの枠に当てはめていた時代には機能していました しかしその世界はもう終わりました今日企業データの80%は非構造化データであり

00:00:57.660 --> 00:01:06.180
メールやチャット音声記録の中に存在しています 従来のパワーオートメートフローではアップルズと4ppl3sを全く別の世界のものとして扱います

00:01:06.180 --> 00:01:15.160
バイナリシステムにとってそれらは全く無関係な文字列にすぎません 私たちは手作業によるデータクレンジングのコストが自動化の価値を上回るという限界点に達しています

00:01:15.160 --> 00:01:22.680
フローを5秒間動かすためにcsvの修正に2時間費やしているなら実際には何も自動化できていません ただ労働を別の場所に移動させただけです

00:01:22.680 --> 00:01:29.440
ai はパワープラットフォームの脇に付け加えた単なる新しい機能ではありません 完全一致から類似性へと向かう根本的な転換なのです

00:01:29.440 --> 00:01:34.960
従来のモデルはこれはaかと問いかけます 新しいモデルはこれはどれくらいaに近いかと問いかけます

00:01:34.960 --> 00:01:39.980
受信トレイをどのように整理しているか考えてみてください 請求書を見つけるために頭の中で正規表現を実行しているわけではありませんよね

00:01:39.980 --> 00:01:47.660
パターンを探しているはずです 文脈を探しているはずです inv202と請求書番号202が文字が一致しなくても同じものであると認識できるはずです

00:01:47.660 --> 00:01:51.180
決定論的システムにはそれができません それらは意図に対して盲目です

00:01:51.180 --> 00:01:56.840
公文しか見ていないからです 2026年に向かう中で公文の重要性は意味論よりも低くなっています

00:01:56.840 --> 00:02:02.960
iotセンサーやリアルタイムストリームllmが生成する要約によってデータ量は爆発的に増加しています

00:02:02.960 --> 00:02:08.060
その量をハードコードされたイフゼン分岐で管理しようとすれば論理は迷宮と化すでしょう

00:02:08.060 --> 00:02:13.920
50もの条件が入れ子になったフローに行き着き ベンダーがメールの署名を変えた瞬間にすべてが壊れることになります

00:02:13.920 --> 00:02:20.520
イフゼンモデルは入力が常にスキーマと一致する完璧な世界を前提としています しかし現実はその逆です

00:02:20.520 --> 00:02:27.120
データこそが変動要因なのです 論理は普遍であるべきですが私たちの論理はあまりに硬直的で現実との接触に耐えられませんでした

00:02:27.120 --> 00:02:32.580
私たちは常に氷が降る世界でガラスの家を建て床が破片だらけになるのを不思議がっているようなものです

00:02:32.580 --> 00:02:41.480
確率論的な設計への移行とはガラスではなくゴムで構築することです それはタイプミスなどの衝撃を受けても粉砕せず吸収できるシステムを作ることです

00:02:41.480 --> 00:02:46.580
システムは100%正しいか100%間違っているかのどちらかでなければならないという考えから脱却する必要があります

00:02:46.580 --> 00:02:52.160
現実世界に100%など存在しないからです 私たちは何十年もの間データの品質について自分自身に嘘をついてきました

00:02:52.160 --> 00:02:57.980
論理のためにクリーンルームを構築しておきながら営業チームからの汚れたデータがシステム障害を引き起こすと驚いたフリをしてきました

00:02:57.980 --> 00:03:04.640
決定論の終焉はその嘘の終焉を意味します それは入力を制御できないという事実を認め処理を近代化しなければならないという決意です

00:03:04.640 --> 00:03:11.740
私たちは近似のエンタープライズ時代に突入しています そこでは完全に間違っているより十分に近い方が価値があることを受け入れます

00:03:11.740 --> 00:03:18.960
なぜなら90%の一致を処理できるシステムは100%の一致以外をすべて拒否するシステムよりもはるかに価値があるからです

00:03:18.960 --> 00:03:26.880
これは単なる技術的な変化ではなく心理的な変化でもあります システムがデータに対してかなり確信しているという状態を受け入れる必要があります

00:03:26.880 --> 00:03:32.940
不確実性を考慮した設計を学ぶ必要があります 構造化されていない情報を扱うにはそれが唯一の誠実な方法だからです

00:03:32.940 --> 00:03:39.340
この転換には日的なトリガーからより繊細な信頼スコアすなわち不確実性のアーキテクチャへと移行することが求められます

00:03:39.340 --> 00:03:46.540
日論理の時代が終わったと受け入れるならそれを新しいフレームワークに置き換えなければなりません 私はこれを公共楽団モデルと呼んでいます

00:03:46.540 --> 00:03:53.240
従来のITアーキテクチャでは全員が厳格な楽譜に従うソロ奏者であり一人が音を外せば演奏全体が止まってしまいます

00:03:53.240 --> 00:04:00.120
しかし確率論的なアーキテクチャでは決定論的な指揮者が確率論的な演奏家を管理します 指揮者となるのはパワーオートメイトのフローです

00:04:00.120 --> 00:04:05.160
フローが構造を提供しテンポを刻み境界線を定義します 演奏家となるのはAIモデルです

00:04:05.160 --> 00:04:14.040
彼らは才能豊かですが表現力も高く演奏するたびに同じ周波数を正確に打つとは限りません 指揮者の仕事は演奏家にロボットのように振る舞うことを強いることではありません

00:04:14.040 --> 00:04:18.240
彼らに耳を傾け奏でる音が次へ進むのに十分な品質かどうかを判断することです

00:04:18.240 --> 00:04:25.920
これこそが現代の設計における中核の柱の部よりスコアなのです 信頼度スコアとは疑わしさの度合いを0から1の値で示したものです

00:04:25.920 --> 00:04:33.020
これはモデルがこれが一致していると思うがどれくらい確信があるかを伝える方法です かつての世界ではハードコードされた経路を使っていました

00:04:33.020 --> 00:04:39.020
メールの件名に請求書が含まれていれば添付ファイルを保存するといったものです 新しい世界では信頼度に基づいたルーティングを行います

00:04:39.020 --> 00:04:47.300
私たちはモデルの内部にある疑念をシステムから見えるようにしているのです AIをブラックボックスとして扱うのではなく特定の信頼性レベルを持つ承認として扱います

00:04:47.300 --> 00:04:54.380
実際にパワープラットフォームでこれを構築する方法をご紹介しましょう アイビルダーやアジュールAIを使用すると抽出されたデータを受け取るだけではありません

00:04:54.380 --> 00:05:03.500
すべてのフィールドに対する確率を示すメタデータレイヤーも取得できます モデルが合計金額1500ドルを抽出した場合その数値に対して95%の確信があることも伝えてくれます

00:05:03.500 --> 00:05:10.720
アーキテクトとしてあなたは今3つの明確なアクションゾーンを持っています まずはグリーンゾーンです信頼度が0.90以上の場合です

00:05:10.720 --> 00:05:17.540
エラーのリスクは低く失敗のコストも管理可能であり自動化の結果が得られます システムは人間の介入なしで処理を進めます

00:05:17.540 --> 00:05:24.620
次にイエローゾーンです信頼度が0.60から0.89の間です モデルはかなり確信していますが確実ではありません

00:05:24.620 --> 00:05:32.440
ドキュメントが少しぼやけていたか手書きの文字が乱雑だったのかもしれません このゾーンではフラグを立てますシステムはデータを人間のレビュアーに転送し素早いチェックを行います

00:05:32.440 --> 00:05:39.620
最後にレッドゾーンです信頼度が0.60を下回る場合です モデルは推測に頼っていますこのゾーンでは拒否またはエスカレーションを行います

00:05:39.620 --> 00:05:47.640
そのデータを本番データベースに近づけてはいけません これは透明性の高いリスク管理レイヤーです安全弁を維持しながら自動化をスケールさせることが可能になります

00:05:47.640 --> 00:05:55.640
ガバナンスへの影響について考えてみてください 決定論的なシステムではエラーは静かに発生しますフローが実行され誤字のために間違った数字を拾いその誤った数値を

00:05:55.640 --> 00:06:01.520
ERPに書き込んでしまいます 市販機の終わりになるまで気づくことはありません確率論的なシステムではエラーにはシグネチャ特徴があります

00:06:01.520 --> 00:06:09.980
システムは自分が苦戦していることを認識し処理はしましたが信頼度は62%でしたと伝えてくれるのです これは非常に強力なシグナルですそれにより疑念ダッシュボードを構築することができます

00:06:09.980 --> 00:06:17.660
モデルがどこで失敗しているかを正確に把握できます どのベンダーがAIで読み取れないドキュメントを送っているかどのプロセスステップが常にイエローゾーンに入っているかを確認できます

00:06:17.660 --> 00:06:24.140
あなたは単にフローを構築しているのではなくインテリジェンスのループを構築しているのです ここでこそアジュールAIとアイビルダーが進化を発揮します

00:06:24.140 --> 00:06:29.780
これらはスコアを詳細なレベルで公開するため特定のテーブルやセルあるいは特定のインテントに対する信頼度を確認できます

00:06:29.780 --> 00:06:40.840
パワーfxを使えば動的な敷地を作成することさえ可能です 例えば50ドルの経費生産なら信頼度は0.70で十分かもしれませんしかし5万ドルの発注書であれば0.98は必要でしょう

00:06:40.840 --> 00:06:48.260
ついに技術的なロジックとビジネス上のリスクを整合させることができるのです 私たちはこれまで全てのデータポイントを同等に扱ってきましたが実際はそうではありません

00:06:48.260 --> 00:06:54.300
確率論的設計により同じフロー内であってもリスクの高い意思決定と低い意思決定を区別して扱えるようになります

00:06:54.300 --> 00:07:00.920
完璧な世界のために構築するのではなく許容できる不確実性の度合いを明確に把握した上でシステムを構築するのです

00:07:00.920 --> 00:07:07.580
スコアを習得すればそのギャップを埋めるロジックに目を向け始められます 曖昧一致ファジーマッチングとセマンティック意味的ロジックです

00:07:07.580 --> 00:07:14.040
ではその中間の不確実な領域にあるデータを実際にどう扱うべきでしょうか まずは完全一致の限界を認めることから始めましょう

00:07:14.040 --> 00:07:19.920
コンテキストを理解できないため完全一致では不十分なのです 従来のモデルではベンダー名にピリオドが一つ足りないだけで検索に失敗していました

00:07:19.920 --> 00:07:25.780
検索ロジックは目的を理解せずただアスキー値を称号するだけだからです そこで登場するのが曖昧一致です

00:07:25.780 --> 00:07:32.640
これは類似度スコアを計算することで非同一のレコードを特定結合する技術であり IBM と IBM のような表記揺れをつなぐ架け橋となります

00:07:32.640 --> 00:07:39.300
そしてその効果は理論上のものではありません 調査によると曖昧一致を導入することで一致率が最大24%向上することがわかっています

00:07:39.300 --> 00:07:47.060
つまりこれまで拒否されていたか手作業での修正のために人間に送られていたデータの24%が救われるのです 大量のデータを扱う環境では数千時間もの時間を削減できることを意味します

00:07:47.060 --> 00:07:50.920
ただしその仕組みを理解しておく必要があります 考え方には大きく分けて2つの方法があります

00:07:50.920 --> 00:07:54.820
一つ目は文字ベースのロジックです これはレーベンシュタイン距離と呼ばれることが多いものです

00:07:54.820 --> 00:07:59.460
ある文字列を別の文字列に変えるために必要な編集回数をカウントします タイプの修正には最適です

00:07:59.460 --> 00:08:06.920
マネージメントと書くべきところをマネージと書いた場合 システムは欠落しているmentを検知し距離を計算してこれらがほぼ同一であると判断します

00:08:06.920 --> 00:08:11.060
2つ目はセマンティック意味的ロジックです ここからが面白いところです

00:08:11.060 --> 00:08:14.660
セマンティックロジックは綴りを気にしません 重視するのは意味です

00:08:14.660 --> 00:08:19.300
片方のシステムがカスタマーもう片方がクライアントと表記している場合 文字ベースの一致では毎回失敗します

00:08:19.300 --> 00:08:22.320
しかしセマンティックモデルであればこれらが同じ意味であることを理解できるのです

00:08:22.320 --> 00:08:30.660
これが文字の一致から概念の一致へのシフトです 信頼スコアとハジーマッチングを組み合わせることでビジネスデータの乱雑な現実に対応できるシステムが構築できます

00:08:30.660 --> 00:08:37.700
人間が少しタイプミスをしただけで壊れるような硬直したルールに縛られることはもうありません あなたはニュアンスを理解できるシステムを構築しているのです

00:08:37.700 --> 00:08:43.280
それこそが単なる自動化から真のデジタルインテリジェンスへと移行し 自己修正型のワークフローを築く方法です

00:08:43.280 --> 00:08:48.180
世界最高のハジーマッチングをもってしてもAIが依然としてハルシネーション 幻覚を起こすという現実と向き合わなければなりません

00:08:48.180 --> 00:08:55.680
それが今の技術の現状なのです 最新のデータによれば最も高度なモデルでさえ15%から20%のハルシネーション率を示しています

00:08:55.680 --> 00:09:02.460
ビジネス向けシステムを構築する際5回に1回の失敗率を無視することはできませんし プロンプトエンジニアリングだけで解決できる問題でもありません

00:09:02.460 --> 00:09:09.000
ハルシネーション率0%の達成は魔法ではないことを受け入れる必要があります それは意図的なアーキテクチャの選択によるものです

00:09:09.000 --> 00:09:16.840
ここからが単純な自動化を超えて回復力のある自己修正型ワークフローの構築を始める段階です そのために私は二重経路検証パターンと呼ぶ構造を用います

00:09:16.840 --> 00:09:24.000
これはAIの創造的な創造力が実際のデータを汚染するのを防ぐセーフガードとして機能します 現代のアーキテクトには一つの基本的なルールがあります

00:09:24.000 --> 00:09:33.840
大規模言語モデル llm に計算をさせてはいけません llm はソフトな推論エンジンであり 意図の理解や大量の乱雑なテキストから特定の詳細を見つけ出すことには長けています

00:09:33.840 --> 00:09:43.740
しかし基本的な算数に関しては統計的に信頼性に欠けます ai に請求書から3つの項目を抽出して合計を計算するよう頼むのはシステムに失敗を求めているようなものです

00:09:43.740 --> 00:09:49.720
自己修正型の設計では乱雑な pdf からのデータ抽出などソフトな推論部分に llm を活用します

00:09:49.720 --> 00:09:54.620
その数値を手に入れたらそれらを決定論的なシステムに渡して厳密な制約を処理させ ます

00:09:54.620 --> 00:10:02.560
パワーオートメイトフローや基本的なルールエンジンこそが加算を行うべき場所です 税金の計算や通貨換算の検証はそれらが行うべきです

00:10:02.560 --> 00:10:09.360
もし llm が合計を500ドルと主張しても計算で480ドルになることがわかれば システムはリアルタイムでハルシネーションを検知したことになります

00:10:09.360 --> 00:10:16.620
システムはクラッシュする代わりにリカバリーパスをトリガーします 別のプロンプトを試すこともあれば人間が確認できるようにエラーとしてフラグを立てることもあります

00:10:16.620 --> 00:10:24.040
これが壊れてしまうフローと自ら修復するフローの違いです 私たちはロボティックプロセスオートメーション rpa においても同様のシフトを目の当たりにしています

00:10:24.040 --> 00:10:31.260
従来の rpa は画面上の正確な座標に依存しているため非常に脆いものです ボタンがわずか3ピクセル左に動いただけでボット全体が失敗してしまいます

00:10:31.260 --> 00:10:41.300
自己修復型 rpa は確率的ビジョンを用いることでそれを変えていくのです ボットはもう特定のピクセル座標を探すことはありませんその代わりにページ上部にある保存アイコンのようなボタンを探します

00:10:41.300 --> 00:10:49.440
インターフェースが変更されてもボットはコンテキストを利用して即座に適用します 新しいレイアウトを認識し自身のロジックを更新してタスクを完了させます

00:10:49.440 --> 00:10:56.620
これによりシステムが潜在的な障害を検知し ユーザーが問題に気づく前に解決への道筋を作るという回復力のあるループが生まれます

00:10:56.620 --> 00:11:05.540
この転換により成功率ではなく復旧率へと焦点が移ります ai を完璧にしようとするのは不可能なのでやめシステムを揺るぎないものにすることに注力するのです

00:11:05.540 --> 00:11:12.960
すべてのトランザクションに牽制機能というレイヤーを組み込むことが重要です ai は気が散りやすい優秀なインターンのように扱うべきです

00:11:12.960 --> 00:11:19.280
何千通ものメールを読むといった重労働は任せても上級監査役の確認なしに小切手に サインさせることは決してありません

00:11:19.280 --> 00:11:26.800
この場合あなたの決定論的高度がその監査役となります 思考と計算を分けることで人間の言語の曖昧さを処理しつつ

00:11:26.800 --> 00:11:33.800
スイスト系のような精度を保つシステムが構築できます こうして ai をテスト段階からビジネスの中核へと移行させるのです

00:11:33.800 --> 00:11:37.860
モデルを信頼するのではなくその周囲に構築したアーキテクチャを信頼するの です

00:11:37.860 --> 00:11:45.640
モデルが時折つまずいてもエラーと見なされないほど強力なセーフティネットを構築します それは単なる自己修正サイクルの構成要素となります

00:11:45.640 --> 00:11:53.180
ラボでは素晴らしい話に聞こえますが実運用では最大のボトルネックは ai ではなく人間が介入する現実です

00:11:53.180 --> 00:11:58.720
ラボでは素晴らしい話ですが実運用において最大のボトルネックは ai ではなく人間なのです

00:11:58.720 --> 00:12:06.540
私たちは自動化を人間か機械かという単純な二択で語りがちですが 確率的な変化により私たちは曖昧な中間領域へと追い込まれます

00:12:06.540 --> 00:12:14.300
業界のベンチマークは非常に厳しい真実を示しています ai ワークフローの約50%は完了前に専門家による確認を必要としています

00:12:14.300 --> 00:12:21.000
これがパイロット運用から本番運用への移行でききが起きる主な理由です 数字を見ると ai パイロット運用プロジェクトの88%が1年以内に失敗しています

00:12:21.000 --> 00:12:27.920
その失敗の理由は技術的な欠陥ではありません設計者がタスクを100%自動化しようと 急ぎすぎるために失敗するのです

00:12:27.920 --> 00:12:33.660
クリーンなテストデータでは機能するシステムを作っても実際の現場の摩擦に直面した 瞬間にロジックが破綻するのです

00:12:33.660 --> 00:12:42.080
人間という要素を無視すると検証の負担が増大することになります ai によってデータ入力が10分短縮されてもチームがそれを信頼できずに確認作業で50分増えて

00:12:42.080 --> 00:12:47.240
しまえば実際には生産性が低下しています それは資産ではなく負債を構築してしまったことになります

00:12:47.240 --> 00:12:54.340
2026年に成功する設計とは検証作業を主要な機能として扱うものです 彼らは人のレビューをシステムの失敗とはみなしません

00:12:54.340 --> 00:13:00.860
むしろアーキテクチャに不可欠な一部として捉えています 彼らは初日からそのレビューコストを投資収益率に組み込んでいます

00:13:00.860 --> 00:13:06.900
これを機能させる秘訣は段階的なレビューロジックにあります これこそが精神をすり減らさずに規模を拡大する方法です

00:13:06.900 --> 00:13:13.820
確信度の高いトランザクションはバックグラウンドで処理されます モデルの確信度が98%で計算が正しければシステムはそのまま進行します

00:13:13.820 --> 00:13:20.040
しかし先ほど触れたイエローゾーンのような確信度の低いケースはエスカレーションを促します これにより人の役割は完全に変わります

00:13:20.040 --> 00:13:26.320
私たちはデータ入力から離れデータ監査へと移行しています 旧モデルでは入力やクリックをすべて行う人間がエンジンでした

00:13:26.320 --> 00:13:33.000
新モデルでは人間はガバナー管理者となります 人間は例外を処理し確率的なモデルが完全には理解できないニュアンスを提供します

00:13:33.000 --> 00:13:39.720
これがチームにとってどのような意味を持つか考えてみてください 実際に難しい5%のケースだけを確認すればいいと分かれば人々の意欲は大きく高まります

00:13:39.720 --> 00:13:44.540
彼らはもうルーティンワークに退屈することはありません 困難なケースの複雑さが彼らの挑戦意欲を刺激します

00:13:44.540 --> 00:13:50.100
しかしこれを機能させるには適切なインターフェースを構築しなければなりません 単に何かがうまくいきませんでしたというメールを送るだけでは不十分です

00:13:50.100 --> 00:13:54.300
サイドバイサイドの比較を表示する必要があります 担当者に元のドキュメントを見せてください

00:13:54.300 --> 00:14:03.080
ai が何を抽出したかを示し確信度スコアが低下したフィールドを正確に強調表示するのです 規模を拡大したいのであれば人のレビューを自動化の弱点とみなすのはやめるべきです

00:14:03.080 --> 00:14:09.940
実際はその逆です うまく統合された人間こそが確率的システムを現実世界で通用する強固なものにします

00:14:09.940 --> 00:14:14.640
それが自己修正型アーキテクチャの最終レイヤーなのです エージェント化の未来

00:14:14.640 --> 00:14:21.500
私たちはエージェント型企業という新しい地平線を見据えています これは今日議論してきたすべてのことの論理的な帰着点です

00:14:21.500 --> 00:14:27.460
エージェントはもはや単なるスクリプトや基本的なフローではなく 一流のデジタルワーカーへと進化する世界へと向かっています

00:14:27.460 --> 00:14:34.460
パワープラットフォームはまさに今目の前で変化しています 標準的なアプリビルダーから完全なオーケストレーションハブへと移行しつつあります

00:14:34.460 --> 00:14:38.240
旧モデルでは特定の課題を解決するために特定のアプリを構築していました

00:14:39.940 --> 00:14:45.680
エージェントが課題を解決してくれる環境を構築します これらのエージェントは単に固定された手順リストに従うだけではありません

00:14:45.680 --> 00:14:54.780
彼らは環境を観察し自身の信頼度を評価して次に使うべき適切なツールを判断します 2026年までにはガバナンスは2年前とは全く異なるものになっているでしょう

00:14:54.780 --> 00:15:01.900
パービューやセンチネルのようなツールは確率的な異常検知へと移行しています もはや流出したパスワードを探すだけではありません

00:15:01.900 --> 00:15:08.160
その代わりに明らかに不自然な行動パターンを探しているのです データ抽出に使われる類似性ロジックを

00:15:08.160 --> 00:15:12.460
テナント全体のセキュリティに適用しているのです この変化は永続的なものです

00:15:12.460 --> 00:15:17.140
厳格なもしならというロジックに固執する人は壊れたシステムと不満を抱えるチームの 管理に追われることになります

00:15:17.140 --> 00:15:22.280
彼らはこのような環境を想定していなかった脆いシステムを修繕し続ける 終わりのないメンテナンスサイクルに陥るでしょう

00:15:22.280 --> 00:15:28.740
エージェント型エンタープライズはある一つの築きから始まります 確実な成果を得るためにあらゆる変数を制御する必要はありません

00:15:28.740 --> 00:15:35.900
私たちが制御すべきはアーキテクチャだけです 私たちの仕事はエージェントがその枠内で動けるよう指揮位置を定義しガードレールを設けることです

00:15:35.900 --> 00:15:43.960
この世界ではビジネスロジックは弾力性を持ちます 新しいベンダーや異なる文書形式にも開発者がコードを一行も書き直すことなく対応できるようになります

00:15:43.960 --> 00:15:49.140
これこそがローコードの真の約束です それは構文の速度ではなく思考の速度で動く能力です

00:15:49.140 --> 00:15:55.580
しかしそこに到達するには今日から始めなければなりません 完璧な世界のための構築はやめ私たちが実際に生きているこの混沌とした世界のために構築を始めましょう

00:15:55.580 --> 00:15:58.680
疑念を受け入れる必要があります 実装の挑戦です

00:15:58.680 --> 00:16:02.380
今週の課題をお伝えします 最も失敗の多いフローを見つけてください

00:16:02.380 --> 00:16:06.800
最も複雑なものを選ぶ必要はありません 不完全なデータが原因で頻繁にクラッシュするものを見つけてください

00:16:06.800 --> 00:16:11.900
目標はデータを修正することではありません ユーザーやベンダーが何を送ってくるかをコントロールすることはできないのです

00:16:11.900 --> 00:16:18.880
その現実に抗うのではなく信頼度敷地を追加してください アイビルダーやllmアクションを開き確率スコアを表示させてください

00:16:18.880 --> 00:16:24.540
シンプルな条件を作成します 信頼度スコアが85%未満の場合はフローをクラッシュさせないようにします

00:16:24.540 --> 00:16:30.560
その特定のケースをレビュー用ホルダーやシェアポイントリストに転送し手動で確認します 成功率がどう変わるか見てみてください

00:16:30.560 --> 00:16:35.140
すべての入力が完璧であるという前提を捨てた瞬間 システムから負荷が取り除かれるのがわかるはずです

00:16:35.140 --> 00:16:42.120
この思考の転換がアプローチを変えたならリンクトインで私ミルコピーターズをフォローしてください 私はこうしたアーキテクチャパターンに関する深い洞察を常に共有しています

00:16:42.120 --> 00:16:48.220
フローが頻繁に壊れているならぜひチームとこれを共有してください 私たちは脆い構築をやめ意図を持った構築を始める必要があります

00:16:48.220 --> 00:16:55.380
これがそのテクニックであり実践し始めればダウンタイムを半分に削減できます プロが使用する高度なバージョンを知りたい方は次の動画をチェックしてください

00:16:55.380 --> 00:17:01.720
チャンネル登録して他のチュートリアルもご覧ください データの厄介な現実に立ち向かうのはやめてそれに対応する設計を始めましょう

00:17:01.720 --> 00:17:07.860
信頼度スコアを使えば壊れやすいフローを実際に機能する強固なシステムに変えられます しかし重要なことがあります

00:17:07.860 --> 00:17:15.020
モデルは正しく構築して初めて機能するのです コパイロットスタジオでの正確な設定方法を知りたい方は今すぐ次の動画をご覧ください

00:17:15.020 --> 00:17:20.260
ai に対する考え方が変わったという方はリンクトインでフォローするかマスターてニューモデルを登録してください