AIエージェントとチャットする？タスクを依頼する？使い分けのポイント

AIエージェントとチャットすることもできますし、タスクを割り当てることもできます。毎日コーディングエージェントを動かしているチームは、この2つを別々のツールとして扱っています。そして、この違いを混同しているチームは、後になってその代償を払うことになります。プライベートなチャット履歴に埋もれた意思決定、完了したのにレビューされないままの作業、そしてセッションがスクロールで流れ去ってから3週間後に「あれってどこで合意したっけ？」と聞いてくる同僚です。

Sharklyは、この区別をプロダクトに組み込んでいます。チャットは、作業を記録として残す必要が生じる前に、エージェントと一緒に探索したり、計画を立てたり、実行したりするためのものです。タスクは、オーナー、ステータス、実行履歴、レビューが必要な作業のためのものです。どちらからでもエージェントの実行を開始できますが、保存される記録は異なり、まさにその違いが本質です。

このガイドでは、それぞれの画面が何のためのものか、Sharklyのチャットモードがどう動作するのか、有望なチャットを実際のタスクに引き継ぐ方法、そしてチームの共有記録を正確に保つための判断ルールを説明します。

TL;DR

タスクを開かずに質問したい、トピックを調査したい、計画を練りたいときは、AIエージェントとチャットしましょう。担当者、ステータス、受け入れ基準、レビュー、あるいはチームが見られる永続的な記録が必要な作業には、タスクを割り当てましょう。チャットのメッセージはセッション内に残り、タスクの結果はタスクに戻り、そこで人間がレビューして承認します。

課題：1つのエージェント、2種類の仕事

ターミナルで Claude Code や Codex を動かしたことがある人なら、この2種類の仕事はすでに知っているはずです。あるセッションは質問です。このモジュールは何をするのか、なぜこのテストは不安定なのか、マイグレーションにはどれくらいコストがかかるのか。別のセッションはコミットメントです。このバグを直す、このエンドポイントを出荷する、このドキュメントを更新する。

ターミナルはどちらも同じように扱います。使い捨ての質問に答えたセッションであれ、チーム全体が依存する変更を生み出したセッションであれ、すべてのセッションは個人のマシン上のプライベートな記録です。質問のセッションはそれで問題ありません。コミットメントのセッションは問題です。なぜなら、他の誰もゴールも、差分も、議論も、結果も見られないからです。

多くのチームはこれを痛い目を見て学びます。開発者がエージェントとチャットしながら本番の修正を進め、修正は出荷される。その根拠は、金曜日にクリアされてしまうスクロールバックバッファの中に生き続けるのです。逆の失敗も起こります。チームがどんな些細な質問もタスク管理ツールに通すようになり、ボードが「キャッシュについて聞く」というタイトルの死んだチケットで埋め尽くされるのです。

解決策は、どちらかの画面を禁止するルールではありません。それぞれの画面が何を記録するのかを理解し、作業を意図的に行き来させることです。まずは、AIエージェントとのチャットが何を保存し、何を保存しないのかを理解することから始まります。

Sharklyのエージェントチャットとは？

エージェントチャットは、エージェントまたはクルーとのスタンドアロンのチャットです。質問したい、トピックを調査したい、計画を練りたい、あるいはタスクを先に開かずに作業を始めたいときに使います。各スタンドアロンチャットは独自のセッションとメッセージを持ち、そのセッションは作成した本人に属します。

Sharklyには2つのチャット画面があり、ドキュメントでは両者を厳格に分けるよう求めています。

• スタンドアロンのエージェントチャットは、どのタスクにも属しません。エージェントのチャットビューを開いてメッセージを送ると、新しいセッションが始まります。これはそのエージェントとのあなた専用のワークスペースです。
• タスク上のエージェントチャットは、そのタスク上に存在します。タスクのコメントではなく、そのタスクがそのエージェントに割り当てられている必要もありません。

ここでは3つの境界が重要です。どれも、常識的に考えれば間違って推測してしまいがちなポイントだからです。

チャットはコメントではありません。エージェントチャットでメッセージを送ってもタスクのコメントは作成されません。タスクのエージェントチャットでメッセージを送っても、アクティビティにコメントとして表示されることはありません。タスクに関する議論の正規の記録はあくまでタスクのコメントであり、チャットはどちらの画面でも別の記録です。

チャットはデフォルトではチームに公開されません。スタンドアロンのセッションは作成した本人に属し、他の組織メンバーは現在のチャットAPIを通じてそのセッションへのアクセス権を得ることはありません。タスク上では、新しいチャットメッセージは担当者と、すでにその会話に参加している人に通知されます。タスクをフォローしている全員にブロードキャストされるわけではありません。

チャットに割り当ては必要ありません。そのエージェントが担当者であってもなくても、タスクを開いてスペース内の任意のエージェントとチャットできます。割り当ては実行の責任を決めるものであって、会話へのアクセスを決めるものではありません。

そもそもエージェントとは何か（指示、ランタイム、スキル、リポジトリを備えた保存済みの作業構成）に馴染みがない場合は、エージェント解説でその基礎を説明しています。

チャットにはない、タスクが提供するものとは？

タスクはSharklyにおける作業の基本単位です。ゴールと説明、ステータス、優先度、ラベル、責任者、実行を担当するエージェントまたはクルー、コメントと添付ファイル、そしてエージェントの実行状態・トレース・結果を保持します。作業に関するすべてがタスクに戻り、アクセス権のある誰もがそれを確認できます。

この一文には、チャットでは実現できない4つの具体的な保証が隠れています。

1. オーナーシップ。 タスクには担当者がいます。何かが止まったとき、そこには名前があります。チャットセッションには参加者のリストはあっても、説明責任の構造はありません。
2. ステータス。 タスクはチームが定義したワークフロー（バックログ、開始済み、レビュー、完了）を進みます。誰でもボードを見れば、聞かなくても作業の現在地がわかります。
3. 実行履歴。 タスクに対するすべての実行はトレースを残します。いつキューに入り、いつ開始され、どのツールを呼び出し、なぜ失敗したのか。実行が壊れたときは、記憶から出来事を再構成するのではなく、実行記録を読めばよいのです。
4. レビュー。 エージェントはタスクを人間の返信待ちや人間のレビュー待ちの状態にできます。これらのシグナルは責任者の受信トレイに届きます。承認は記録されたステップであり、雰囲気ではありません。

タスクベースの実行には構造的な利点もあります。タスク上のリポジトリ作業は分離されたディレクトリ（通常は実行ごとに別の git worktree）で行われるため、複数のタスクが同じコードベースを並行して変更しても互いに干渉しません。その仕組みはSharklyがエージェントを並行実行する方法で説明しています。割り当て済みのタスクへのフォローアップコメントは新たな実行を開始でき、Sharklyは短時間に連続したコメントをまとめて、重複した作業が発生しないようにします。

実作業にふさわしい場所がタスクである理由は、人間とエージェントの契約にあります。エージェントはタスクについて調査し、実行し、テストし、報告します。人間は方向性を示し、権限を与え、結果を承認します。チャットセッションはこの契約の前半を支えますが、後半を支えるのはタスクだけです。

エージェントチャット vs タスク割り当て：判断表

判断の決め手は、作業の大きさではなく、何を記録に残す必要があるかです。

質問している、比較している、調査している、形を整えているときはチャットを使います。担当者、ステータス、受け入れ基準、あるいは誰かの承認が必要な結果を伴う作業にはタスクを使います。

これを教条主義にしないための、正直な反則ルールが2つあります。

すべての質問にタスクを作らないこと。「このモジュールは何をするのか？」はチケットではなくチャットにふさわしい。質問の形をしたタスクで埋まったボードはノイズであり、本当の作業を埋もれさせます。ノイズこそ、人間とエージェントのための作業管理システムが防ぐために存在するものです。

チャットをいつの間にかプロジェクトにしてしまわないこと。会話がチームとして対応・レビュー・記憶すべき何かを生み出した瞬間、それはセッションの枠を超えています。チームが結論を見る必要があるなら、タスクの説明かコメントにコピーしましょう。元のセッションはあなたのプライベートな履歴として残り、タスクが共有の記録になります。

3つのチャットモード：Explore、Plan、Execute

Sharklyのチャットは単一の挙動ではありません。入力欄には3つのモードがあり、選択したモードはセッションとともに保存され、どのターンの前でも変更できます。

Explore は読み取り専用の調査です。エージェントは変更を加えずに調査し、説明し、比較し、要約します。分析だけが欲しいときはExploreを選んだままにしましょう。「認証フローを説明して」や「この2つのライブラリのうち、コードベースがすでに依存しているのはどちら？」にぴったりのモードです。

Plan は、エージェントがレビュー用にアクションを提案できるようにします。エージェントはサブタスク付きの計画タスクを下書きし、あなたが確認するまで何も起きません。提案を編集したり、作業を開始せずに確定したり、確定してすぐ開始したりできます。プランモードは良い会話と追跡されるコミットメントをつなぐ橋であり、チャットからタスクへの引き継ぎを手軽にしてくれるモードです。

Execute は、エージェントが設定済みのCLIを通じて直接行動し、結果をセッションに返せるようにします。デフォルトを変更していなければ、新しいチャットはExecuteで始まります。これは初日から知っておく価値があります。読み取り専用の会話にしたいなら、エージェントが何かを始めてからではなく、最初のメッセージの前にExploreに切り替えましょう。

モードに関する判断のペアは、より大きな判断を反映しています。結果がまだ問いである間はExploreかPlanを使います。Executeをチャットで使うのは、チームの記録から外れていても構わない作業だけにし、それ以外はすべてタスクを使いましょう。

いくつかの挙動が、実際のチャットを使い心地よくしてくれます。エージェントの出力は実行中にセッションへストリーミングされ、いつでも実行を停止できます。エージェントが作業している間に別のメッセージを送ると、Sharklyは並行して重複実行を始めるのではなく、次のターン用にキューに入れます。同じブラウザでチャットを切り替えたとき、未送信の下書きテキストは会話ごとに保持されます。セッションは名前変更、アーカイブ、履歴からの再オープンが可能で、アーカイブされたセッションは読み取り専用で閲覧できます。

チャットをタスクに引き継ぐ方法

引き継ぎは2つの画面が出会う場所であり、Sharklyのドキュメントでは具体的な手順が示されています。議論がコミットすべきアクションを生み出したときは、次のようにします。

1. チャットで成果を要約する。 ゴール、スコープ、制約、受け入れ基準を1つのメッセージで述べるようエージェントに依頼します。これがタスクに必要な段落であり、エージェントはそれを書くための文脈をすでに持っています。
2. プランモードでタスクを下書きする。 Planに切り替えて、タスクとサブタスクを提案させます。提案をレビューし、確定前に編集しましょう。これを省略して手動でタスクを作成してもかまいません。大切なのは、人間がコミットメントの形を決めることです。
3. 開始するかしないかを選んで確定する。 確定すると計画タスクが作成されます。今すぐ作業を始めるべきなら確定して開始、スプリントや依存関係を待つべきなら開始せずに確定します。
4. 割り当てる。 担当者コントロールで、適切な人、エージェント、またはクルーにタスクを回します。適切にスコープが切られたチャットの要約があってこそ、割り当てが可能になります。複数の役割を伴う作業なら、リーダーエージェントを擁するクルーが単一の実行者ではなくタスク全体を引き受けられます。
5. 移すのは文脈であって、会話ログではない。 タスクが保持すべきものは説明やコメントにコピーしましょう。チャットセッションはあなた個人の履歴として残ります。チームは見られないのですから、チームの記憶として頼ってはいけません。

それ以降、フィードバックはタスクのルールに従います。タスク固有のやり取りはタスクのエージェントチャットで続け、チーム全体が見るべき結論はアクティビティのコメントに書きます。割り当て済みタスクへの条件を満たすコメントはフォローアップ実行を開始します。結果、ブロッカー、最終的な回答はタスクに戻り、それが後からのレビューを可能にします。

配置に関する注意点が1つあります。エージェントに割り当てられたタスクは、バックログにある間は開始されません。バックログは待機場所です。タスクをバックログから移動すると、コンピューターとランタイムの準備が整い次第、割り当てられたエージェントが開始します。つまり、今チャットから作業を段取りしておき、チームの準備ができたときにリリースできます。実行が物理的にどこで行われるかは別の話で、コンピューター解説で扱っています。

クイックチャット：タスクを離れずにタスクの文脈を使う

基本を押さえたら知っておきたい3つ目の画面があります。タスク詳細のヘッダーツールバーにあるクイックチャットです。保存されたプロンプトとエージェントの組み合わせで、現在のタスクを文脈として実行されます。

各クイックチャットには名前、任意のプロンプト、選択したエージェントまたはクルー、公開設定があります。プライベートなクイックチャットは作成者だけが表示・実行できます。共有クイックチャットはスペース内の全員が表示できますが、編集できるのは作成者だけです。1つを選ぶと、左にタスク、右にチャットの分割ビューが開き、プロンプト、エージェント、タスクの文脈がまとめて送信されます。

これにより、繰り返し発生する質問がワンクリックの操作になります。「Estimate this」という名前でタスクを計画エージェントに送る共有クイックチャットや、リポジトリを理解するエージェントにつないだ「Find related code」は、スペース内の誰もがあらゆるタスクで実行できるものになります。これはスキルを貫くのと同じ考え方です。価値は、各人がより多くのチャットを開くことではなく、良いセットアップを共有することから生まれます。

押さえておきたい仕組みが2つあります。クイックチャットの実行はそれぞれ独自のタスクレベルの会話を作成し、その会話はタスク上に残ります。割り当てられたエージェントの通常のチャットを再利用するわけではありません。また、クイックチャットを削除すると保存された設定が削除されるだけで、そこからすでに作成された会話は削除されません。

自分のスタックにタスク層がない場合は？

オーケストレーション基盤を一切使わずにエージェントを動かしているチームはたくさんあります。生のターミナルセッション、tmuxペイン、シェルスクリプトなどです。そうした構成でも、この記事で述べた区別のチャット側はそれなりに機能します。ターミナルセッションは、エージェントチャットと同じく、エージェントとのプライベートで探索的な会話です。

DIYスタックに欠けているのはもう半分です。担当者も、ステータスも、同僚が開ける実行トレースも、レビューのステップも、結果がデフォルトで着地する場所もありません。すべてのコミットメントセッションがすべての質問セッションと見分けがつかず、その違いは何かが壊れて誰も原因を再構成できなくなったときに初めて表面化します。Claude Squad、Conductor、tmuxベースの構成の比較では、それぞれのアプローチがどこで止まるのかを解説しています。

欠けている半分を足すためにプロセスを作り直す必要はありません。SharklyはClaude CodeやCodex、その他の実行ツールを置き換えるものではありません。チームがすでに使っているツールの周りに、共有タスク、文脈、レビューの層を追加するものです。モデルの利用は、それらのツールで設定したサブスクリプションやAPIキーを通じて引き続き行われます。ターミナルでの走り書き作業が好きなら、そのまま使って構いません。コミットした作業はタスクを通すようにしましょう。チケットがすでに別の場所にある場合は、Jiraチケットをそのままエージェントに渡すこともでき、チームがトラッカーを乗り換える必要はありません。

3つのシナリオで具体的に見る

不安定なテスト。 あるエンジニアが、テストが断続的に失敗することに気づきます。彼女はチームのコードリーダーエージェントとのチャットをExploreモードで開きます。「並列実行時に auth_session_test が失敗するのはなぜ？」10分ほど読んだ後、エージェントは競合状態のある共有フィクスチャを指摘します。ここからはコミットメントです。彼女はPlanモードに切り替え、エージェントが修正範囲と受け入れ基準（「テストが並列実行50回連続で成功する」）を含むタスクSH-341を下書きし、確定して開始し、修正担当エージェントに割り当てます。調査は彼女のチャット履歴に残ります。修正、差分、レビューはSH-341に着地します。

アーキテクチャの問い。 あるテックリードが、キューを導入した場合に3つのサービス全体でどれくらいのコストがかかるかを知りたいと考えます。これは何日もかかる読解作業ですが、それでも問いであることに変わりはないので、「queue adoption study」と名前を変えたスタンドアロンのチャットセッションに留めます。1週間かけて彼女はそのセッションに戻り、追加の質問をし、エージェントに選択肢を比較させます。経営陣がゴーサインを出したとき、そのセッションの最終的な要約がエピックレベルのタスクの説明になり、Planモードでサブタスクに分解されます。途中で中途半端に追跡されることは一切ありませんでした。

繰り返し戻ってくるスタンドアップの質問。 あるチームは、毎朝誰かが、レビュー中のタスクについて昨日の変更を要約するようエージェントに頼んでいることに気づきます。1人がそれを「What changed here?」という共有クイックチャットとして保存し、リポジトリを理解するエージェントにつなぎます。質問を打ち直す必要はなくなり、実行のたびにその会話が対象のタスクに残ります。オンデマンドではなくスケジュールで要約を得たいなら、同じ発想がオートメーションに発展します。

3つすべてにおいて、どの画面を使うかは同じルールで決まります。問いはチャットに留まり、コミットメントにはタスクが与えられ、答えが作業を意味した瞬間に引き継ぎが行われます。

まとめ

探索しているときはAIエージェントとチャットし、コミットするときはタスクを割り当てましょう。Sharklyは2つの画面を意図的に分けておくことで、ボードには質問ではなく実際の作業が記録され、あなたの質問が誰も読まない記録に消えていくこともありません。チャットセッションはあなたのものです。タスクはチームのものであり、文脈、進捗、ブロッカー、結果、人間によるレビューが、依頼からリリースまで見える形で残ります。

両方の画面はすでに目の前にあるので、この区別を取り入れるのにコストはかかりません。エージェントとのチャットを開いて、普段ならコードベースを掘って調べるようなことを聞いてみましょう。その会話がコミットする価値のある何かを生み出したら、Planモードに切り替えてタスクを下書きさせましょう。コンピューターを1つ接続し、エージェントを1つ作成し、退屈な作業で両方の半分を試してみてください。準備ができたら、フラッグシップの概要でプラットフォームの残りを説明しています。

よくある質問

タスクを割り当てずに、そのタスクについてエージェントとチャットできますか？

はい。タスクを開いて、スペース内の任意のエージェントとチャットを始められます。割り当ては会話の前提条件ではありません。割り当ては誰がタスクを実行するかを決めるものであって、誰と話せるかを決めるものではありません。

チャットのメッセージはタスクのアクティビティフィードに表示されますか？

いいえ。コメントはチーム全体のアクティビティに表示されます。タスク上のエージェントチャットは担当者と、すでにその会話に参加している人に通知され、どちらの画面でもコメントとは別に保存されます。

チームメンバーは自分のスタンドアロンのエージェントチャットセッションを読めますか？

いいえ。各スタンドアロンセッションは作成者に属し、他の組織メンバーは現在のチャットAPIを通じてアクセスできません。結論がチームにとって重要なら、タスクの説明かコメントにコピーしましょう。

オフラインまたはアーカイブ済みのエージェントにメッセージを送るとどうなりますか？

オフラインのエージェントは「考え中」や「キュー待ち」ではなくオフラインとして表示されるので、来ない返信を待たないようにしましょう。アーカイブ済みのエージェントは新しいメッセージを受け取れません。入力欄が無効になりますが、セッション履歴は読み取り可能なままです。

どのチャットモードから始めるべきですか？

デフォルトを変更しない限り、新しいチャットはExecuteで始まります。変更を伴わない分析が欲しい場合は、最初のメッセージを送る前にExploreに切り替えましょう。エージェントにタスクを提案させ、それをレビューして確定したいときはPlanを使います。

エージェントとのチャットはタスク実行の設定を使いますか？

はい。チャットの実行も同じエージェント設定（指示、ランタイム、コンピューター）を通ります。Executeモードでは、エージェントはタスク実行を支えるのと同じ仕組みである、設定済みのCLIを通じて行動します。

チャットはいつタスクにすべきですか？

会話が、誰かが所有・レビュー・記憶しなければならない作業を生み出した瞬間です。ゴール、スコープ、制約、受け入れ基準を要約し、Planモードまたは手動でタスクを下書きし、割り当てましょう。チャット履歴はチームの記録ではありません。

2人が1つのエージェントチャットセッションを共有できますか？

スタンドアロンセッションは単一オーナーなので共有できません。タスク上では、エージェントチャットが担当者と以前の参加者に通知するため、少人数のグループならそのタスクレベルの会話を一緒に追えます。チーム全体に見える議論にはタスクのコメントを使ってください。