01
プロセスには目に見える定義があります
プロセスが誰か一人の操作の習慣の中にしか存在しないと、レビューもできず、引き継ぎもできません。チームの誰もが開ける定義が必要です。
Braidrunのやり方
各ワークフローはYAML定義であり、キャンバスとコードが双方向で同期します。8種類のステップタイプが、単一Agent、コード、分類器、複数Agentの議論、ステートマシン、サブワークフローをカバーします。
コンセプトガイド
AI Native とは？
「AI Native」は今広まりつつある言葉ですが、意味は人によってまちまちです。このページでは、実践的な定義、判断方法、そして5つの質問によるセルフチェックリストを示します。
定義
3つの行動でAI Nativeを定義します
AI Nativeが表すのは業務プロセスがどう動くかであり、チームがいくつAIツールを購入したかとは直接関係ありません。あるチームがAI Nativeかどうかを判断するには、次の3つの行動を確認します。
RUN
プロセスはAIが実行します
業務プロセスはスケジュールまたはイベントによって自動で実行されます。人は逐一操作するのではなく、重要な操作の承認と例外の処理だけを担います。
LOG
実行ごとに記録が残ります
各ステップが何をしたか、入出力は何か、いくらかかったかを、後から1件ずつ確認でき、問題が起きても具体的なステップまで特定できます。
TEAM
プロセスはチームのものです
プロセスは共有された定義として書かれており、新しいメンバーも理解でき、引き継いで変更もできます。誰か一人のチャット履歴の中に閉じ込められてはいません。
判定方法
ある思考実験。アカウントを取り上げるか、プラットフォームを止めるか
2つの仮定の事柄をそれぞれ想定し、どちらが業務への影響が大きいかを比べます。
A
ChatGPTアカウントを1つ取り上げる
チームで最もAIを使いこなすメンバーのチャットアカウントを取り上げると仮定します。よくある結果は、そのメンバーの効率は下がるものの、業務そのものは通常どおり進むというものです。
B
自動化プラットフォームを1日止める
チームが使っているワークフロープラットフォームを1日止めると仮定します。朝のレポートが誰からも届かず、承認待ちの変更が滞り、スケジュール実行がすべて止まるなら、業務プロセスはすでにAIの上で動いているということです。
2つの実験の違いが、「AIを使う」とAI Nativeの違いです。チャットのアカウントは個人のツールで、取り上げても影響するのは一人の効率だけです。ワークフロープラットフォームは業務プロセスを担っており、止めると影響するのはチーム全体の成果です。
セルフチェック
5つの質問で、自分のチームを採点します
「はい」と答えるほどAI Nativeに近く、多くが「いいえ」なら、AIはまだ個人ツールの段階にとどまっているということです。
- 01
チームが使っている自動化プラットフォームを1日止めたら、影響を受ける業務プロセスはありますか？
- 02
先月AIがあるプロセスにいくら費やしたか、具体的な数値を確認できますか？
- 03
AIが予算を変更したり、コンテンツを公開したり、本番データに書き込んだりする前に、必須の人の承認ステップがありますか？
- 04
AIの実行で誤った結果が出たとき、エラーの起きたステップを特定し、そのときの入出力を確認できますか？
- 05
プロセスを作ったメンバーが2週間休暇を取っても、ほかの人がこのプロセスを理解し、安心して変更できますか？
比較
「AIを使う」とAI Nativeを項目ごとに比較します
同じ事柄を、2つの働き方でどう扱うかの違いです。
| 観点 | AIを使うチーム | AI Nativeなチーム |
|---|---|---|
| 能力の入口 | 各自のチャットウィンドウ | チームで共有するワークフロープラットフォーム、各プロセスに名前と定義があります |
| ノウハウの保存 | 使いやすいプロンプトは個人のお気に入りに保存されます | プロンプトはワークフロー定義に書き込まれ、チーム全体が同じバージョンを使います |
| 失敗処理 | 手動でもう一度実行し、聞き方を変えて再試行します | 実行記録を確認してエラーのステップを特定し、そのステップから再実行します |
| 監査 | 問題が起きたらチャット履歴をさかのぼります | 実行ごとにログがあり、重要な変更には承認記録があります |
| コスト計算 | 月末にサブスクリプションの合計請求書を1枚確認します | 実行ごとのtoken使用量とコストが1件ずつ記録されます |
| 拡張方法 | AIを使える人をもう一人採用します | ワークフローを複製し、パラメーターを変えて2つ目の業務を動かします |
エンジニアリング要件
AI Nativeを実現するには、エンジニアリング上で4つのものが必要です
各項目の下にはBraidrunの対応する仕組みを記載しており、登録後に1つずつ検証できます。
02
重要な操作には必須の承認があります
AIは間違えることがあります。予算の変更、コンテンツの公開、本番データへの書き込みといった操作は、実行前にいったん停止して人の確認を待ちます。確認ステップはプロセス定義に書き込んでおくことで、スキップされなくなります。
Braidrunのやり方
manual_approvalステップは実行を一時停止し、App内、メール、またはAPIで承認者に通知します。承認されると続行し、却下またはタイムアウトの場合は停止して本番環境は一切変更しません。承認リストの数値は直接変更でき、例えばAIが提案した入札を小さくしてから承認できます。
03
実行ごとに完全な記録を残します
AIの出力は毎回異なる可能性があります。問題が起きたとき、どのステップが誤ったか、そのときの入出力は何か、この実行にいくらかかったかに答えられる必要があります。
Braidrunのやり方
実行ごとにタイムラインがあり、ステップごとにログ、token使用量、コストを記録します。実行の過程はJSONまたはYAMLでエクスポートできます。失敗後は指定したステップから再実行でき、完了済みのLLMステップは重複して課金されません。
04
モデルとデプロイは差し替えられます
モデルの更新は速く、今日の適切な選択が半年後には変わっているかもしれません。プロセス定義とモデルは分離しておくべきです。モデルを差し替えるときに、プロセス自体を書き直す必要はありません。
Braidrunのやり方
自分のモデルのAPI Keyを使えます。15社以上のプロバイダーとローカルのOllama、LM Studioに対応し、1つのワークフロー内で各Agentに異なるモデルを設定できます。認証情報はAES-256-GCMで暗号化して保存し、オンプレミス配置にも対応します。
FAQ