AGI Cockpitの使い方、最初のタスクからAutorunの定期実行まで解説

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。

たとえば、こんな場面を想像してみてください。月曜のLIVEが終わって、文字起こしが手元にある。ブックマークした記事も、週の途中で10本たまっている。で、どれも「記事にしたい素材」なんですが、記事にする手が足りない。

AIには頼めます。文字起こしをチャットに貼れば、それらしい下書きは出てきます。

問題はその先です。修正の依頼、途中の確認、画像を入れるかどうか、公開していいかの判断。ここを全部、自分の手元に持ったままにすると、素材は増えても記事は増えません。

私は今、この「依頼から公開判断まで」の流れを、AGI Cockpitというアプリの上に置いています。

AGI Cockpitは、AIに仕事を「タスク」として渡す道具

AGI Cockpitは、パソコンの上で動く複数のAIエージェントに仕事を渡して、進み具合と確認の要求と成果を一か所で見るためのデスクトップアプリです（公式ドキュメント）。

チャットと何が違うのか。一番の違いは、仕事が「会話」ではなく「タスク」という単位になるってことです。

チャットは、1つの画面に会話が流れていきます。仕事を2つ3つ頼むと、話が1本の川に混ざりやすい。

Cockpitでは、依頼ごとにタスクを作ります。目的と、作業する場所と、担当するAIを指定して開始する。これが公式の「最初のタスク」の手順です（最初のタスク）。プログラムを書く人向けの道具に見えるかもしれません。でも、依頼文は日本語の文章です。コードが必須という意味ではありません。

タスクごとに会話が分かれるので、LIVE記事の話とブックマーク記事の話が混ざらない。実行中、確認待ち、完了、エラーの状態が一覧で見えます。

もう一つ。Cockpitは、クラウドの上で勝手に動くサービスではありません。AIのプロセスも作業ファイルも、Cockpitを動かしているパソコンの側にあります。私の場合はMacです。パソコンを止めれば止まる。

ただし、パソコンの中で完結するという意味ではありません。Claude CodeやCodexのようなAIエージェントを使う場合、多くは依頼の内容がそのサービスのクラウドへ送られます。通信の条件は、使うエージェントごとの設定に従います。ここは最初に知っておいてよい点かな。

私の実際の使い方：素材を渡す→作る→成果物を見る→Askで直す

実物で説明します。AI経営術LIVEの「会社OS」の回を、ブログ記事にしたときの話です。

元の配信は、私とれんくんが話した回。文字起こしを素材にして、記事制作のタスクを1つ立てました。担当のAIが下書きを作り、WordPressに下書きとして保存して、できた段階で私にAskが届く。

Askって何かというと、AIが作業を止めて、人に判断を渡す仕組みです（Ask）。選択肢をタップして答えることも、自由に文章で返すこともできます。

で、この記事のAskに私が返した答えが、これでした。

jevの話は？全容入ってるかサブエージェントでフルチェック

短いですが、要望が2つ入っています。配信の冒頭で話したJevの話が抜けていること。それと、配信の全容が入っているかを、別のAIに通しで確認させてほしいこと。

担当のAIは、Jevの節を追加しました。そこからさらに修正が入って、私が公開のGOを出しました。

今の記事はこれです。本文に画像が13枚、Jevの節、動画の時間指定リンクが入っています。

Claude Codeチーム共有の「会社OS」は、NASとMac Studio一台で作れると分かった

ここで言いたいのは、記事の出来ではありません。同じタスクの会話の中に、私の要望と、修正と、成果物と、公開の判断が全部残っているってことです。

「あれ直した？」って聞くとき、探す場所が1つで済む！チャットの履歴をさかのぼらなくていい。どの会話だったかを思い出す必要もない。

ちなみに、時間がどれだけ減ったかは測っていません。測っていないので書きません。

素材が違っても、形は同じです。ブックマークした記事から作ったTokusetsuの紹介記事も、対話の記録から生まれた記事も、「タスクで作る→成果物を見る→Askで判断する」の同じ形で公開まで行きました。

• 個人開発ツール「Tokusetsu」を13年続けた佐野章核さんが解説（素材はブックマーク）
• やりたい事が先で、学びが後に生まれる順番（素材は対話の記録）

毎回頼む仕事と、定期的に任せる仕事は分ける

タスクは「今回これをやって」と、そのつど立てるものです。一方で、毎日決まった時間に、同じ形で始めたい仕事があります。

それを担当するのがAutorunです。指定した時刻や間隔で、新しいタスクを作るか、既存のタスクへ指示を送ります（Autorun）。複数のAIを連携させる機能ではなく、同じ仕事を決まったタイミングで始めるための機能です。AGIラボ会員向けの機能で、Cockpitのアプリが動いているパソコン側で実行されます。

私のブログ便はこれで動いています。朝は7時30分。昼は12時30分。夜は9時30分。この1日3回、「素材をブログ化して、画像なしの下書きを作って、私にAskを出す」という指示で、新しいタスクが立ちます。

この記事を書いている時点で、このAutorunは有効で、直近の便でもタスクが作られた記録があります。ただ、ここで一つ区切りを入れます。

起動したことと、記事が完成したことって、別なんです。

実際にあった例を出します。海外の比較動画を素材にした便では、WordPressに下書きが保存されて本文は入っていましたが、画像は0枚！届いたAskで私が選んだのは「下書きを仕上げる（外部には出さない）」。担当のAIは、画像の制作を別の工程として残しました。

定期起動は、公開までを自動でやる魔法ではありません。仕事を「始める」ところを任せて、「出す」ところは私に戻ってくる。私はこの分け方にしています。

Autorunの設定画面では、毎日・毎週・毎月のかんたん設定で時刻を選べるようになりました（4.87.0で追加）。毎日1回の便なら、cron式を書かずに時刻を選ぶだけで済みます。

通常のタスクから始めます。同じ依頼を1回動かし、下書きが狙いどおりに出るかを見る。それから定期実行へ移します。Autorunの使い方は、公式では次の流れです。

1. 画面左下のアプリメニューから「自動実行タスク」を開き、「新規作成」を選ぶ。
2. 名前と依頼文を入れ、実行先を「新規タスクを作成」か「既存タスクへ送信」から選ぶ。毎回別の素材を扱うなら、新しいタスクにすると履歴を分けられる。
3. 新しいタスクでは、作業フォルダー、AIエージェント、承認モードも確認する。
4. 実行タイミングで「Cron」を選び、かんたん設定で毎日・毎週・毎月と時刻を選ぶ。保存後に次回実行時刻を確かめる。

依頼文には、素材の場所と、どこまで作れば終わりかを書きます。私のブログ便なら「画像なし下書きまで。公開判断はAskで戻す」が区切りです。

一人のAIでよい仕事と、複数の担当に分ける仕事

短い文章を整えるだけなら、タスク1つから始めます。記事の根拠を別の目で確かめたいなら、確認だけを別のAIに任せる。同じ順番の仕事を繰り返すときに、Fleetを検討します。

一番軽い分け方は、確認だけを別のAIに任せることです。先ほどのAskで私が頼んだ「サブエージェントでフルチェック」がこれ。書いた本人が自分で確認するより、別の目が入ったほうが抜けは見つかりやすい、という考えで頼んでいます。

分け方そのものに判断がいる大きな仕事なら、Master Agentという役割があります。目的を渡すと、複数のタスクへの分け方を考えながら、進行中に担当や優先順位を調整してくれる仕組みです（Master Agent）。手順が毎回同じで、依存関係が決まっている仕事ならFleet。調査→執筆→検証のように、依存関係をYAMLで書いて、1つのRunとして実行します（Fleet）。単発の作業を1つ別タスクへ渡すだけなら、どちらも要りません。

この記事の2節を、Fleetで作らせてみた

材料はこの記事の2節です。この節と、次のスマホの節を使いました。事実確認→編集→検収の3工程を、依存関係のあるFleetとして動かしています。

事実確認の担当には、公式の操作ガイドと元の2節、以前の実験記録を渡しました。編集の担当には同じ資料に加えて、前工程でできた根拠台帳を渡し、2節分の本文を作らせました。最後の検収担当は、本文と根拠台帳を一次資料と照合し、修正点を返しました。3工程は順番に進みました。最後まで完了しています。

検収からは、本文の要修正5件と、根拠台帳への注意1件が返ってきました。主な指摘は、AIが行った統合作業を「私が」やったように書いていたこと、4つの工程のうち実際に最後まで終わったのは一部だけなのに全部やったように読めたこと、接続方式の説明が公式の推奨と逆になっていたこと、更新の効果を実測なしで言い切っていたことです。これらはこの記事に反映しました。

ただし、検収の指摘も間違うことがあります。今回は完走後、統合担当のAIが元の本文と照合すると、「書かれていない」とされた説明が実際には書かれていました。その1件は誤検出です。採用しませんでした。3工程の実行中、人や親のAIから担当タスクへの追加指示はありません。検収結果の照合と、この記事への採用・修正は、完走後にFleetの外で行った追加作業です。

以前、別の教材（出版企画の本文と演習）を本文担当と演習担当に分けて試した時は、私の環境の自動巡回が担当タスクへ直接メッセージを送り、Fleetがその介入を検知して2回中断しました。そのときは統合と検収をFleetの外で引き取り、AIによる4ケースの検収では3件合格・1件を「確認が必要です」に直しています。この修正は前回指摘との差分照合であり、4ケースを新しく再試験したものではありません。

分けるかどうかの目安は変わりません。成果物が1つで担当も1人で終わるならタスク1つ。確認だけ別の目がほしいなら単発の委任。分け方そのものに判断がいるならMaster Agent。同じ手順を依存関係ごと繰り返すならFleet。今回のFleetはmax_parallelを1にして、事実確認→編集→検収の順番が意図どおりに引き継がれるかを確認するためのもので、並列化による速さの比較はしていません。単独のタスク1つで同じ2節を書いた場合との速さ・費用の優劣も、担当数や検収の有無という条件自体が違うため比較していません。

実務としてのコストも見えました。担当ごとに依頼文と受け渡すファイルを事前に揃える準備が要り、書き漏らしがあれば後工程の担当全員にそのまま伝わります。もう一つ、私の環境のように稼働中のタスクへ自動で割り込む仕組みが別にあると、Fleetがそれを外部からの直接介入と検知して一時停止することがあります。試行中だけ通知を調整しました。終了後、設定は元に戻しています。Autorunと組み合わせて毎日回すのは、同じ依頼が1回、狙いどおりに通ってからです。今回はこの記事1回の試行です。定期運転は未検証です。

実画面で見る：AIからAIへ、何を渡して何が返ったか

実行日は2026年9月25日です。環境はMac、Cockpit 4.89.0。対象はこの記事の「複数の担当に分ける仕事」と「スマホ」の2節。記事全部を作る試験ではありません。準備と実行は、私の依頼を受けた担当AIが行いました。

最初に渡したのは、元の2節を保存した sections-before.html と公式ガイド5ファイルです。内容はリモートアクセス、タスク管理、Master Agent、Fleet、バージョン履歴。それに、前回の出版企画の試行記録5ファイルを照合対象として指定しました。

指示も「いい感じに」では止めません。根拠確認の担当へ渡した実際の指示には、次の一文を入れています。

fleet-facts.jsonにclaim/source/verification記録。

つまり、記事の主張・出典・確認できた範囲を、次の担当が読めるファイルに残す指定です。「スマホ実機は未確認」「AIだけが行った検証はAI側の作業と明示」も、各担当への共通条件にしました。

この間、人が文章をコピーして次のAIへ貼る操作は入れていません。Fleetの依存関係を使い、前の担当が終わると次へ進む形です。ファイル名と受け渡す順番は、先に担当AIが設定しました。

Runの記録は8時47分45秒開始、9時6分27秒終了。約18分42秒です。依頼文を作る準備と、完走後に本文を直して採用する時間は含みません。同時実行数も1なので、速さを競うテストにはしていません。

画面の1工程目を押すと、担当モデルや実行回数まで開けました。「完了」と書かれた報告だけで済ませず、どの担当が動いたのかをここで読み戻しています。

3/3完了は、文章がそのまま公開できるという意味ではありません。今回の検収担当には、指摘が残っていても検収を終えたら完了を返すよう指定しています。実際、返ってきた本文には直す箇所がありました。

別のAIを入れて、実際に直ったところ

たとえば、編集AIの本文にはこう書かれていました。

できた原稿を私が引き取って統合しました。

でも、実行記録では統合したのは親のAIです。「私」はこの記事の著者である田中啓之。そこで、本文を「統合と検収をFleetの外で引き取り、AIによる4ケースの検収では…」と直し、AIの作業だと分かる説明にしました。人がやったこととAIがやったことを混ぜないための修正です。

接続方法にも修正が入りました。編集AIの原稿では、ローカルWi-FiのHTTP接続の説明から、そのままPWAをホーム画面へ追加する流れに読めました。今の本文では、ホーム画面への追加はHTTPSで開いた後、と接続方式を分けています。

検収AIの誤りもありました。「4ケースを再試験していない説明が欠けている」という指摘です。ところが元の原稿には、次の一文がありました。

この修正はもとの回答との差分確認で、4ケースを再試験したわけではありません。

統合担当のAIが現物を読み直し、この指摘は採用しませんでした。別のAIを入れる価値は、見落としを探す目が増えること。ただし、その目も間違う。指摘の件数だけで出来を決めず、元の文章と照合するところまでが今回の作業です。

今のブログ便なら、どこにFleetを使うか

おすすめは、出典が複数あるAIツール解説の記事です。今回のCockpit記事のように、公式の説明と手元の実測を分ける仕事に当てはめます。

今のブログ便は、Autorunが担当のAIを起動し、画像なしの下書きができたらAskで私に戻します。Fleetを使う変更案では、同じ素材を「根拠台帳を作る→下書きを書く→別のAIが照合する」の順に渡します。戻るものは、下書きと指摘一覧です。私が読む前に、出典と実測の食い違いを確認する工程が入ります。ただし、指摘自体が間違うこともあります。今回も1件ありました。

次の1手は、該当する記事1本で、この3工程をもう一度動かすことです。台帳と下書きと指摘が揃うかを確かめます。定期便への切り替えは、その結果を見て決めます。時刻を変える必要はありませんが、起動時の依頼をFleetの実行へつなぐ準備と、独自の通知が割り込まない設定の確認が要ります。今回、Autorunの設定は変更していません。

短い文章の整形や、素材1件をそのまままとめる便は、今のタスク1つが出発点です。担当を増やす前に、どの確認を分けたいかを決める。Fleetで減らせるのは工程間の受け渡しで、出典の確認や公開判断まで不要になるわけではありません。

Roomで相談し、Fleetで制作する。実際に使った5つの場面

Talk Roomsも、実際に使っています。AI氣道の読者について考える会議、AIツールを選ぶ会議、記事と販売のつなぎ方を検討する会議です。記事制作と料理の発信素材づくりでは、Fleetも動かしました。

使い分けは、相談か、制作か。

Roomは、違う役割のAIが同じ会話を読み、意見を交わす場所。Fleetは、前の仕事の結果を次の担当へ渡し、決めた工程を進める仕組みです。以下は2026年8〜9月の保存済み会話・実行記録を確認した例です。最新版だけで再現した試験とは分けて紹介します。

Roomの実例① AI氣道の「読者」を一括りにしない

「AI氣道の読者は誰か」を考えるRoomには、進行役、書き手の分身役、検索から来る読者役、買い手の読者役が入りました。いずれもAIです。

会話では、検索されている言葉だけで読者の職業までは決められない、という指摘が出ました。ツールを調べに来る人と、サイトが継続して届けたい相手も同じとは限りません。

そこで、「検索記事の入口」と「中心に届けたい読者」を分けて考える候補が整理されました。会話は17メッセージ。ただし、これは本人不在の事前討議です。AIが読者像を決定したわけではありません。

Roomの実例② 20個のAIツール候補を5個へ絞る

Hugging Face Spacesの候補を選ぶ会議では、20候補を持ち込みました。実務で使えるか、発信の題材になるか、技術的に試せるかを別々のAIが検討し、5候補に絞っています。

単なる多数決ではありません。

動画の文字起こし・要約ツールについては、品質を確認できていないという異論が出ました。それでも試す価値はあるとして、「品質を保証するおすすめ」ではなく「未知を測る試験枠」として残しています。選定理由と未確認事項が、同じ会話に残りました。

これは当時の選定結果です。候補5件すべてを実機で検証した、という意味ではありません。

Roomの実例③ 売り文句を、元の発言と照合する

販売設計の会議には、進行役、買い手役、制作役、販売役が参加しました。「毎日7本」という表現案に対し、制作役が元の発言を確認。「ある日、7本ぐらい」という話を、毎日の実績として広げないよう訂正しています。

記事の話題と売る商品のつながりにも指摘が入り、その記事には講座への案内を付けない方針が会議内でまとまりました。足りない商品情報は、推測で埋めずに残しています。

買い手役はAIです。本物のお客さんが買いたいと言った証拠にはなりません。それでも、書き手だけでは見落とす表現の飛躍を探す、という使い道は具体的に見えました。

Fleetの実例① 文字起こしから記事の下書きまで

別の記事制作では、文字起こしを渡し、定義の整理・事実確認・読者のつまずきの検討を分担。構成3案から1案を選び、見出しごとの執筆、統合、別のAIによる審査へ進めました。

最初の審査は、指摘12件。

たとえば「最後まで成功する割合が約60%」という説明が、「60点の原稿」という品質の点数にすり替わっていました。修正担当が直し、次の審査記録では残り0件。その後、機械検査とWordPressへの下書き保存へ進んでいます。

実行記録では16工程が完了しています。これはAI担当だけの人数ではなく、機械検査なども含む数です。先行する実行には停止・失敗もあり、最初から一発で完成したわけではありません。公開まで自動化した実例でもありません。

Fleetの実例② おからパンケーキを画像8枚と動画にする

既存のおからパンケーキの素材を使い、「素材の準備→画像制作と動画制作→検品」の4工程を試しました。画像と動画は担当を分けましたが、この試験は同時実行数1。並列化で速くなったという比較ではありません。

残っている制作物は、1080×1350の画像8枚と、1080×1920・18.4秒の動画。動画には音声トラックもあります。

生成できただけでは終わりません。

画像担当の検品記録には、初回のまとめページなどで文字切れを見つけ、試験用の生成スクリプトを修正した経緯が残っています。機械検査では枚数・寸法・動画の尺・音声などを確認。投稿予約や公開は、この試験に含めていません。

発信の仕事なら、まずどちらを使う？

「素材はある。でも誰に何を伝えるか決まらない」ならRoom。「記事、画像、動画の作り方が決まっていて、担当間の受け渡しが多い」ならFleet。短い文章1本を直すだけなら、通常のタスクからで十分です。

たとえば、私が「この素材を記事にして」とだけ渡すと、切り口の相談と制作が混ざります。分けるなら、まずRoomで読者役と制作役に論点を出してもらう。私が切り口を選び、AIにその条件をFleetの各担当へ渡してもらう。最後に下書きと画像を見る、という頼み方ができます。これは上の実例を踏まえた使い方の提案で、自動でRoomからFleetへ接続した検証ではありません。

注意点も3つあります。RoomはAI同士が納得しても事実とは限らないので、結論に出典と未確認事項を残す。Fleetは完了表示だけでは文字切れや言い換えの誤りが分からないので、現物を検品する。工程を増やすと待ち時間とAI利用量も増えるので、最初は1件に絞り、元の素材を残して通常のタスクに戻せる形で試す。この3つは外せません。

スマホから指示する使い方と、最新版4.90の更新

公式のバージョン履歴に載っている最新版は4.90.0です（2026年9月25日公開、公式ドキュメントで確認）。手元のMacは4.89.0で、これはCLIで確認済みです。最新版は自動更新でインストールしていません。なので、ここは公式の記述と、担当のAIがMac側で確かめたことを分けて書きます。

スマホから記事の修正を頼むまでの手順

準備は先にパソコン側です。Desktopの「リモートアクセス」画面で「Tailscale限定」を選ぶと、接続情報にURLとQRコードが出ます。Tailscaleは、パソコンとスマホの両方にインストールし、同じtailnetに参加していれば使えます（同じTailscaleアカウントでなければならない、という意味ではありません。複数アカウントが同じtailnetに参加している場合もあります）。証明書を取得して「HTTPS接続」をオンにすると、URLはhttps://端末名.tailnet名.ts.net:47280の形になります。スマホでこのURLを開くか、QRコードを読み取って開き、デバイス認証が出たらDesktop側に表示された6桁のペアリングコードを入力します。ホーム画面への追加は、このHTTPSのURLを開いた後に行います。「ローカルWi-Fiも許可」を使ったLAN経由のHTTP接続は暗号化されません。ホーム画面へ追加するPWAには、ここで説明したHTTPSのURLを使います。Tailscale＋HTTPSが唯一の方式ではありませんが、公式の推奨構成です（リモートアクセス）。

接続できると、PWAには「受信箱」「タスク」「自動タスク」の3画面があります。タスク一覧からこの記事のタスクを開き、下のメッセージ欄に修正の指示を書いて送ります。例えば「スマホ操作の説明を3手順にしてください。公開しないでください。」のような1点の修正です。送った指示はパソコン側で動いているのと同じタスクの会話に追加され、できあがった修正はそのタスクの会話とタスクパネル（差分やHTML Surfaceなど）で読みます。パソコンでもスマホでも、見ている場所は同じ1つのタスクです。

今回、担当のAIがMacの内蔵ブラウザーで確かめたのは、リモートアクセスへの接続、受信箱、タスク一覧、この記事の会話と入力欄までです。Fleet担当タスクでは、3工程の完了表示と、会話の横にFleetパネルが並ぶ表示も確認しました。スマホ実機から修正指示を送り、結果を読み直す往復は、まだ試していません。

リモートアクセス自体は会員向けの機能で、スマホがAIを動かすのではなく、パソコン側のタスクをスマホから見て操作する仕組みです。手順として書けるのは、パソコンを稼働させたままリモートアクセスを設定し、PWAで同じタスクを開き、修正の指示を送り、結果を読む、という流れまでです。

PWAは、どこまで操作して確かめたか

ここはスマホ実機ではなく、担当AIがMacの内蔵ブラウザーで試した記録です。画面幅を狭くしても、スマホの検証とは数えていません。

1. 設定済みのTailscale＋HTTPSのリモートアクセスを開く。接続後、「受信箱」と「タスク」の画面を確認。
2. タスク一覧からこの記事のタスクを開く。同じ会話と、下部のメッセージ入力欄を確認。
3. この記事のタスクパネルで「HTML Surface」を選ぶ。用意した記事のHTMLプレビューが表示され、タイトル・画像・本文を読めることを確認。
4. Fleetの検収担当タスクも開く。「Fleet」タブで3/3完了を確認し、工程を押して担当の詳細を読む。

確認できたのは、同じ仕事の会話と成果物へ、リモートアクセスの画面からたどり着けることです。新しい端末のペアリングは未実施。ホーム画面へのインストールも未実施です。入力欄から修正指示を送る操作も未実施です。

スマホで送信→MacのAIが修正→スマホで結果を読む、という往復の使い心地は、まだ結論を出せません。ここまでを実画面で確かめた範囲として載せます。

9月25日公開の4.90.0と、ピン留めの実機確認

9月25日公開の4.90.0では、サイドパネルのAskタブで保留中の質問を確認して回答できるようになり、Askのウィンドウを自動で開くかどうかを端末ごとに設定できるようになりました。確認が重なるときに使う機能です。これは公式の説明です。実機ではまだ試していません。

回答のピン留め機能（4.89.0で追加）は、CLI経由で試しました。Codexが担当したタスクの回答をピン留めし、一覧に反映されたことを確認したうえで、解除して元の状態に戻しています。Desktop・PWA画面でピン留めボタンを押す操作と、アプリを再起動した後もピン留めが残るかは確かめていません。

ピン留めでは、同じタスクのCodex回答1件を指定しました。操作後の一覧には1件が入り、回答を参照できる状態を表す available: true が返りました。解除後は空の一覧です。実際の応答から、判定に使った部分だけを抜粋します（回答本文・識別子は省略）。

ピン留め後の一覧：
"pinned": [{ "available": true, … }]

解除後の一覧：
"pinned": []

これはCLI経由の追加・読み戻し・解除の確認です。画面のピン留めボタンを押した証拠としては扱いません。

Askをどの画面で確認するか、回答をどう残すか。最新版では、こうした日々の操作にも更新が入っています。この記事の公開判断は、引き続き私に戻す運用です。

導入前に知っておくこと、そして最初の1件

ここまで読んで「入れてみようかな」と思った人に、先に分担の話をします。

AGI Cockpit本体がやるのは、タスクを作る、状態を見る、Askを受ける、成果物を見る、という「監督の場所」の役目です。実際に文章を書いたり調べたりするのは、Claude CodeやCodexなどのAIエージェントで、それぞれのサービスに応じた認証や利用条件の準備が要ります。

そして、私のブログ便のように「文字起こしから記事の下書きを作ってWordPressに保存する」という手順は、私が自分の環境に積み上げてきたスキルや外部連携です。Cockpitを入れただけで、この便が付いてくるわけではありません。

成果物の確認は、タスク画面の右側のサイドパネルでできます。差分、ファイル、HTMLのレポート、アプリ内ブラウザーで開いたページ。会話を離れずに見られます（成果とツール）。ただし、見られることと正しいことは別です。中身を読むのは、人の仕事のままです。

最初の使い方は、既存の素材から下書きまで

公式の「最初のタスク」では、ファイルを変更しない短い依頼から始める手順になっています。それに倣って、最初は手元の素材1件で、下書きまでを頼むのがよいと思います。

依頼文の例を1つ置きます。これは私が実際に送った文ではなく、例です。

この文字起こしファイルを読んで、ブログ記事の下書きを日本語で作ってください。
見出しは5つ以内。公開はしないでください。
話の中で私が言っていないことは書かないでください。
迷った点があれば、作業を止めて私に選択肢で聞いてください。

素材は先にコピーしておきます。画面上部の「新しいタスク」を開き、そのコピーを置いた専用フォルダーを作業場所にします。次に、担当のAIを選びます。上の依頼文を入力します。承認モードは「監督」です。これは公式手順に沿っています。ただし、作業場所の指定だけで、ほかのファイルへのアクセスを完全に防げるとは考えないでください。

で、下書きができたら読む。直したいところがあれば、同じタスクに文章で返す。この往復が、そのまま「任せ方」の練習になります。

始める前に知っておくリスク

• 大事なファイルを書き換えてしまうリスクがあります。最初は素材のコピーを使い、差分や出来たファイルを確認します。おかしければ作業を止め、元のコピーから戻します。
• パソコンやCockpitが止まっていると、予定した仕事が始まらないことがあります。Autorunの実行履歴と作成されたタスクを見て確かめます。動かし直す前に同じ仕事がすでに始まっていないかを確認し、二重の依頼を避けます。
• AIの下書きに抜けや誤りが残るリスクがあります。元の素材と見比べ、修正は同じタスクに返します。公開・送信は確認後に進めるよう、依頼文と承認設定を揃えます。Askがあるだけで、すべての外部操作が自動的に止まるわけではありません。

今回この記事で確かめたこと、確かめていないこと

• 確かめた：LIVE記事のタスクに、Askの回答と修正と公開の履歴が残っていること。現行記事が公開状態で、画像13枚とJevの節があること
• 確かめた：ブログ便のAutorunが有効で、直近の便でタスクが作られた記録があること。別の便で下書きは保存されたが画像0枚で、私が「下書きを仕上げる」を選んだこと
• 確かめた：前回の4.88.0時点で、選択肢と自由文を一緒に返した回答が、別々の項目として記録されること
• 確かめた：この記事自体の2節を、事実確認→編集→検収の3工程Fleetで作らせ、3工程とも完了したこと。検収から本文の要修正5件・根拠台帳への注意1件が返り、うち1件は元の実行記録と照合して誤検出と判断し除外したこと
• 確かめた：旧N01（出版企画の本文と演習）でFleetを非公開で1回試し、本文ノードは完了、演習は直接の通知介入で2回中断したこと。統合と検収はFleet外で行い、AIの初回回答は4ケース中3件合格だったこと
• 確かめた：Mac内蔵ブラウザーでリモートアクセス経由の接続・受信箱・タスク一覧・この記事のタスクの会話・メッセージ入力欄まで（指示の送信はしていない）
• 確かめた：MacのブラウザーでFleet担当タスクを開き、3/3完了と、会話の横にFleetパネルが並ぶ表示を確認したこと
• 確かめた：手元のMacが4.89.0であることをCLIで確認したこと。Codex回答のピン留め→一覧反映→解除をCLI経由で確認したこと。公式の最新版が4.90.0（2026年9月25日公開）であること
• 確かめていない：スマホの実機でのリモートアクセス接続〜指示送信〜結果確認の一連操作。4.90.0の実機（Askタブ、端末ごとの自動表示設定）。PWA画面でのピン留めボタン操作とアプリ再起動後にピン留めが残るか。Fleetの並列化による速度差、単独タスクとの費用・所要時間の優劣。同じ依頼をAutorunで定期的に繰り返す運用。RoomのAI読者役の意見が、実際の顧客の反応と一致するか

よくある質問

Q. プログラミングができなくても使えますか？

タスクの依頼文は日本語の文章です。公式の最初のタスクも「フォルダの構成を説明して」という依頼で、コードは書きません。ただし、Claude CodeやCodexなどのAIエージェント側の準備は別に必要です。

Q. 入れれば記事が自動で公開されますか？

されません。Autorunは仕事を始めるところまでで、公開の判断はAskで私に戻す運用にしています。それに、私のブログ便の手順はCockpitに標準で入っているものではなく、自分の環境で組んだものです。

Q. スマホだけで完結しますか？

しません。エージェントの作業はパソコン側で動きます。スマホの役目は、見ること、答えること、それと指示を送ることです。リモートアクセスは会員向けの機能で、今回はスマホ実機での検証をしていません。