IMPLEMENTATION / 2026-10-11実装ノート
公式連携で仕事を回す

Dots(ドッツ)のダッシュボード、自作しなくてよくない? 公式連携を使って気づいたこと

自作ダッシュボードの複雑な設計図を脇に置き、会話・タスク・実装・通知をつなぐ構成を考える男性

Dots(ドッツ)を使うためのダッシュボードを、自分で作り続ける必要はなかったのかもしれない。公式の案内に沿ってChatGPT、Linear、Slack、Codexをつないで使ってみると、今の自分の用途では、思っていたほど不便を感じなかった。

Xを見ていると、複数のAIエージェントの進捗を一覧にする画面を作っている人をよく見かける。自分もCodexを使い、作業状態や停止理由、次のアクションを確認する「AI管制室」を作っていた。AIに仕事を任せるなら、その動きを見るための専用画面も必要だと思っていたからだ。

ところが、既存サービスにつなぎ、仕事の持たせ方を整理していくと、欲しかった機能のかなりの部分はすでに用意されていた。自作した経験があるからこそ、「これ、作らなくてもよかったのでは」と感じている。

管理画面を作ると、その画面を管理する仕事も増える

自作ダッシュボードは、作ったら終わりではない。見やすい表示へ直し、進捗データの整合性を確かめ、状態更新や通知をつなぎ、不具合があれば修正する。AIに開発を任せられても、何を直すか決め、結果を確認する時間はかかる。

そもそも自分が欲しかったのは、AIに任せた仕事がどこまで進み、何が止まっていて、次に何を判断すればよいか分かる環境だった。その環境を作ろうとして、専用の画面を選んでいた。

そこで、進捗を保存する場所や通知の窓口まで、自分で抱える必要があるのかを考え直した。タスク管理はLinearにあり、連絡にはSlackがある。ドッツからそれらを使えるなら、自作画面に同じ機能をもう一度載せなくても仕事は回せそうだった。

チャティが調整し、Linearに状態を残す

今はドッツを使ったAIアシスタント「チャティ」を、仕事を調整する窓口として使っている。チャティに相談や依頼を渡し、調査・制作・実装・テストはCodexへ任せる。その仕事の状態を残す場所はLinearに寄せる構成だ。

ツール自分の運用で持たせている役割
チャティ情報整理、作業の手配、進捗確認、通知
ChatGPT相談、依頼、提案や結果の確認
Codex調査、制作、実装、テスト
Linearプロジェクト、タスク、状態を残す基準の場所
Slack外出先からの会話、通知、確認依頼への対応
Wiki運用ルール、判断基準、定例情報の参照

Linearに残すのは、人間の仕事だけでなくAIへ渡した仕事も同じでよい。「Todo」「In Review」「Done」のような状態があれば、何が未着手で、何をレビューし、何が終わったかを追える。チャティが結果を確認して更新する流れを組めば、自分でタスクを登録し、毎回状態を変える操作も減らせる。

大事なのは、状態を確認する基準の場所を決めることだった。Wikiにはルールを置き、Linearには仕事の状態を置く。自作ダッシュボードにも同じ情報を保存すると、どちらが最新かを確かめる仕事が増える。今はLinearを基準にして、そこへ情報を集める方が扱いやすいと感じている。

チャティを中心に、ChatGPTとSlackを本人の窓口、Codexを実作業、Linearをタスクと状態の基準にした仕事の流れ
チャティを中心にした仕事の流れ(2026年10月10日の構成図)

図は自分の運用構成を整理したものだ。LinearからSlackへの通知連携は、接続・動作ともに確認済みである。定例も設定済みである。

Slackに戻ってくれば、PCの前で待たなくてよい

Slackでは通知を受け取り、外出先からチャティと会話し、確認依頼に答えて必要な指示を返す。この窓口を、仕事の流れに組み込んでいる。

組もうとしているのは、チャティがCodexへ仕事を渡し、返ってきた結果を確認してLinearを更新し、人間の判断が必要なところでSlackへ戻す流れだ。自分は通知を見て、内容を確認し、必要な回答や承認を行う。

こうなれば、個々のAIがどうなったかを確認するために、自宅のPCを開いて作業画面を巡回する場面は減らせる。スマートフォンで会話できる窓口があるだけでも、自作画面を開きに行く前提は変わる。

公式の利用案内にも、ドッツとSlackを接続する方法や、接続したPCでWork・Codexのタスクを作る機能が載っている。自分専用の管理画面を作る前に、こうした接続でどこまで進められるかを試せたはずだった。OpenAIのドッツ利用案内

ただ、Slackに戻ってきた依頼をすべて自動承認する運用にはしていない。公開や重要な変更は本人の承認を必要とする。確認する場所を変えても、自分が決める範囲は残す。

カフェでスマートフォンの通知を読み、AIに任せた仕事への回答を考える男性
外出先でも通知を読み、判断が必要なところで会話へ戻る。

公式連携で足りるなら、そこから始めればよかった

特別なダッシュボードを作らなくても、既存の機能と接続で思ったより困らなかった。Linearにはタスクと状態の管理があり、Slackには会話と通知がある。それらの間をドッツが調整する構成にすると、自分が一から用意したかったものの形に近づいてきた。

もちろん、接続ボタンを押すだけですべて完成するわけではない。どこに仕事を残し、誰が状態を更新し、どの時点で自分へ確認を戻すかは決める必要がある。それでも、表示画面や通知機能まで開発することに比べれば、既存のサービスで試せる範囲は広かった。

ドッツと外部アプリの接続とは別に、LinearとSlackの間にも公式の連携設定がある。自分もこの設定で連携し、通知が届くことを確認している。LinearのSlack連携の案内

ChatGPTの接続アプリも、使える操作はアプリや接続時の権限によって変わる。情報を読めても、更新や送信までできるとは限らない。今回の感想は、自分が今使っている構成での手応えである。OpenAIの接続アプリの案内

AIで作れるようになった分、不便があるとすぐ「Codexで作ろう」と考えていた。この1年でいろいろ作った経験は役に立っている。だからこそ今回は、自分で保守するものを増やす前に、公式に用意された接続を使う方が早かったのではないかと思った。

定例を設定したことと、安定して回ることは分けて見る

今の構成には、日々の情報確認も組み込んでいる。Gmailは毎日12時と17時、Slackの「気になるメモ」は毎週金曜19時に確認する設定だ。時刻は日本時間である。Wikiのルールや判断基準を参照し、対応が必要ならLinearへ登録・更新して、判断が必要な内容をSlackへ戻す流れを考えている。

メールを見て、用事を拾い、タスクに登録する。その一連の操作をチャティへ任せられるなら、単発の制作だけでなく日常の管理も軽くできそうだ。

ただし、運用は組み始めた段階である。定例の変更後の初回実行や、失敗したときの戻し方まで確認できたわけではない。Linearの表示が「Done」でも、実際の成果を確認せずに完了扱いにはしない。

これから確かめたいのは、タスクの登録や更新が正確か、実際の作業結果とLinearの表示が合うか、定例が予定どおり動くか、Slackから必要な対応を終えられるかという点だ。管理時間が何時間減ったかを測れたわけでも、完全自動化ができたわけでもない。

今の段階で言えるのは、こうした確認を進めるために、自作ダッシュボードが必須だとは感じなくなったことである。

GmailとSlackの定例チェック、Wikiの参照から、チャティによる整理、Codexへの依頼、結果確認、Linearの更新、Slackでの通知と本人承認までの流れ
定例チェックから、タスクの登録・更新、本人への確認までの流れ。

足りない機能が見えてから、必要な部分だけ作る

自作ダッシュボードを作ってみたことで、自分が見たかった情報や管理したかった仕事は分かった。その経験を、今はLinearやSlackの使い方へ戻している。

まずはこの構成で使い続け、どうしても足りない機能が出てきたら、その部分だけ作ればよいと思っている。ダッシュボードを維持するために時間を使うより、任せた仕事の結果と、次に必要な判断を確かめる方へ時間を戻したい。

ドッツを使い始めて、仕事を預けられる範囲は広がった。今度は、その仕事を管理する仕組みまで、自分で全部作る必要があるのかを見直している。

参考・引用元

機能の案内は2026年10月11日に確認。本文の体験と運用設定は提供された原稿・図・今回の説明に基づく。図は運用構成の説明用であり、すべての連携が動作確認済みであることを示すものではない。