ワークフロー自動化
複数の AI モジュールが同じ仕事を奪い合うなら、直すべきは誰が書き込めるか
一つのイベントで複数の AI モジュールが起動し、互いの結果を上書きし合うとき、多くのチームはまず仲裁ルールを足そうとする。より効くのは設計に戻ることだ。一つの事柄に入口は一つ、変更される項目ごとに書き込めるモジュールは一つ、ほかは提案だけにする。
tag
AIエージェント
同じトピックのミニクラスをまとめて読み、最新記事から文脈を補えます。
4
lessons
タグ導読
AIエージェント
AI エージェントや常駐アシスタントが作業者になるとき、先に決めるべき境界を扱います。
AIトレンドと産業
AI を仕事の流れにつなぐ前に、いつ止まって人に聞くかを決めておく
AI がいつ止まって人に聞くべきかは、モデルが自分で「自信がない」と言うのに頼れない。止まる条件は、システムから見える出来事として書いておく。重要な項目の欠け、情報源どうしの矛盾、次の手順が外に何かを送ること、中断後に状態がわからないこと。止まるときには、ほかの人が引き継げる記録も残す。
ワークフロー自動化
ノーコードで誰でも AI アシスタントを作れるなら、権限は接続ごとではなく操作ごとに渡す
Asana は、コードを書かずに AI アシスタントを作れる StackAI を買収した。自社の AI Teammates は、つないだ十以上のアプリで検索し、読み、書き込める。ツールにつながったからといって、AI がそのツールの中のすべてをしてよいわけではない。作る人は操作ごとに権限を分ける。何を自動にし、何を下書きだけにし、何を名前のある人の承認にするか。公開の前には、わざと一度失敗させてみる。
AIトレンドと産業
サイトに AI 用の入口は必要か。その仕事が「読む」「調べる」「動く」のどれかで決まる
サイトに API や MCP が必要かは、AI がやる仕事が公開情報を読むことか、変わるデータを調べることか、人の代わりに動くことかで決まる。三つの入口が負う責任は違い、多くのサイトがまず直すべきは AI が読める公開ページだ。