Coworkのアーティファクトでタスク実行画面を作る

定期的に走らせたい作業が、気づけば10個近くに増えていました。

毎朝それぞれを思い出して起動するのは、地味に億劫な手間です。

そこで私は、ボタンを並べただけの小さな「実行画面」を自作してみました。

使ったのは、Coworkの「アーティファクト」という仕組み。

特別な開発環境もデプロイも要らず、1枚のHTMLがそのまま手元のツールになる手軽さに、すっかり助けられています。

同じように、走らせたい作業が少しずつ散らかってきた経験はないでしょうか。

なぜ「タスク実行画面」を自作したのか

最初に、この画面が欲しくなった背景から書きます。

定期タスクが増えると、起動が地味に面倒

タスクを一つずつ仕込むのは、最初こそ楽しい作業でした。

ところが数が増えると、今度は「どれを、いつ動かしたか」が自分でも見えなくなっていく。

サイドバーの一覧を毎回スクロールして探すのも、回数が重なると無視できない小さな摩擦になります。

ちょうど、増えすぎたアプリのアイコンを毎回フォルダから掘り出すような、あの面倒くささです。

しかも一覧をたどるだけでは、最後にいつ走らせたのかまでは一目で分かりません。

欲しかったのは、全部を一覧して、押すだけで動かせる一枚の盤面でした。

アーティファクトという「持ち帰れる画面」

Coworkのアーティファクトは、ひとことで言えば連携データを読み込んで動く自己完結のHTMLです。

普通のメモと違い、開くたびに最新のデータを取りに行ってくれる点が決定的に便利なのです。

作っては消える使い捨てではなく、明日もまた開いてそのまま使える道具になる。

マニフェストで使うMCPツールを宣言する

作り方の入口は、HTMLの先頭に置く小さな設定ブロックです。

ここで「この画面がどのツールを呼ぶか」を、あらかじめ宣言しておきます。

宣言を怠ると、画面の中からそのツールを呼んでも動いてくれません。

<script type="application/json" id="cowork-artifact-meta">
{
  "name": "Task Dashboard",
  "mcpTools": ["mcp__scheduled-tasks__list_scheduled_tasks"],
  "mcpServerNames": ["scheduled-tasks"]
  // ... 省略（description など）
}
</script>

宣言したツールだけが、画面の中から呼び出せるようになる。

いわば、画面に持たせる通行手形のようなものだと考えると分かりやすいでしょう。

ワンクリック実行はAPIひとつ

肝心の「実行」は、拍子抜けするほど簡単でした。

ボタンのクリックに、用意された関数をひとつ繋ぐだけです。

btn.addEventListener("click", async () => {
  btn.disabled = true;             // 二重起動を防ぐ
  await window.cowork.runScheduledTask(taskId);
  btn.textContent = "実行開始 ✓";  // サイドバーで走り始める
  // ... 省略（失敗時にボタンを戻す処理）
});

これを繋いだだけで、サイドバーのタスクが実際に走り始めます。

待っているあいだ、ボタンの文字を「起動中」に変えておくだけで安心感が段違いでした。

やりたいことは「一覧して押す」だけ、という当たり前を取り戻せた、そんな手応えが確かにありました。

一歩進んだ作り込みと落とし穴

ただ動かすだけなら、ここまでで十分です。

もう一歩、使い心地を上げる工夫と、そこで踏んだ落とし穴も共有します。

最終実行日時をライブ取得する

押すだけの盤面に、私は「いつ最後に動かしたか」も並べたくなりました。

そこで連携ツールを呼び、一覧データから各タスクの実行日時を取り込みます。

const r = await window.cowork.callMcpTool(
  "mcp__scheduled-tasks__list_scheduled_tasks", {});
// 戻り値は {content, structuredContent, isError}
let tasks = r.structuredContent ?? JSON.parse(r.content[0].text);
// ... 省略（非表示タスクの除外と日時の差し込み）

戻り値は整形済みのstructuredContentを優先し、無ければテキスト側を自分で読み解く。

この二段構えにしておくと、取得の仕組みが多少変わっても画面が壊れにくくなります。

地味な工夫ですが、変化に耐える設計はいつもこういう細部から生まれてくる。

よくある落とし穴：取得に失敗すると盤面が固まる

ここで一度、派手に失敗しました。

ライブ取得に頼り切った結果、通信が空振りしたときに肝心の一覧がまるごと出てこない。

データが取れない瞬間に、画面が無言で固まってしまうのは、最悪の体験です。

そこで、あらかじめHTMLの中へ前回時点のデータを書き込んでおく方針に切り替えました。

ライブ取得はあくまで上書きの「ベストエフォート」と割り切り、失敗しても素の表示が残るようにしたのです。

コツ：描画は軽く、覚える状態は最小限に

最後に、長く使い続けるための小さなコツを挙げます。

凝ったライブラリは持ち込まず、素のJavaScriptで描画を組み立てる。

そのほうが読み込みも速く、後から自分で直すときにも迷いません。

並び順や絞り込みのような「覚えておいてほしい設定」だけ、ブラウザの保存領域にそっと逃がせば十分です。

全部を作り込もうとせず、あえて手を抜く場所を先に決めておくのも長続きのコツだと感じています。

凝るよりも、壊れにくく直しやすいほうが結局は長持ちすると痛感しました。

最後に

たった1枚のHTMLが、いつのまにか毎日の作業の入り口になっています。

特別な道具をそろえなくても、手元の困りごとは案外こうして小さく解決できる。

大げさな仕組みを構える前に、まず自分の手に馴染む一枚を作ってみる。

そんな軽い気持ちの工作が、思った以上に日々を助けてくれています。

以上です。