ブログの更新、ニュースのキャッチアップ、コードの整理——気づけば「見張るべき場所」が増え続けているのに、一日の時間は全く増えてくれません。
「AIに任せればいいじゃないか」とは思うものの、勝手に記事が書き換えられたり、コードが消されたりするのは困るという怖さもあって、なかなか一歩踏み出せずにいました。
そこで私が辿り着いた発想の転換が、「観察と提案だけ任せる、実行と最終判断は自分」という線引き です。
Coworkの定時タスクを使って、この設計で毎日動かしている活用例を5つ、体験ベースでまとめました。
毎日を回すペインと向き合う
2人の子どもを育てながらエンジニアとして働いていると、サイトを毎日確認して、ニュースを追って、コードを整理して、というルーティンはどれか一つが必ず抜け落ちていく。
「全部ちゃんとやりたい」という気持ちはあるのに、現実がついてきません。
そこで一時期、AIに全部任せようとしたことがあります。
ところが「勝手に既存記事のトーンを変えてほしくない」「確認なしにコードを消されたら困る」という不安が次々と浮かんで、委託と恐怖がセットになってしまったんですよね。
その葛藤を解消してくれたのが、「実行は自分がやる、でも観察と気づきと提案の言語化だけ先にやっておいてもらう」という役割分担 の発想でした。
Coworkの定時タスクは、このモデルとすごく相性がよく、「朝起きたらレポートが届いている」という形で毎朝の出発点になっています。
朝刊化｜生成AIニュースをレポートに
毎朝、生成AI領域の直近ニュースを自動収集して、「見出し・要約・業務への示唆」の3点セット にまとめて届けてもらうタスクから一日が始まります。
このタスクの役割は、情報収集そのものを代行することです。
各ソースを巡回して新着を拾い、「自分の仕事に引き寄せるとどういう意味があるか」まで言語化してくれるのが、単なるRSSリーダーとの大きな違いになります。
成果物は「開いてすぐ読める1枚のレポート」として完結していて、チャット履歴を遡らなくても情報が手に入る ようにしています。
実装で特に効いているのが、タスクに「やってはいけないこと」を先に書いておく設計です。
「確認できない情報源の予測や推測は含めない」「既知の発表を新発見のように書かない」といった制約を明記しておくと、届くレポートの信頼感が段違いに上がりました。
情報感度を落とさずに情報収集の時間を消せる というのが、このタスクで得られた一番の成果ですね。
サイト改善ループ｜ブログの巡回と提案
自分のブログを毎日巡回して、「軽い改善提案」と「次記事のタイトル案・メモ案」 を出してもらうタスクも毎日動かしています。
「次に何を書けばいいか分からない」という状態は、ブログを続ける上でかなり体力を奪うペインです。
このタスクのおかげで、毎朝「今日書けそうなネタ」が手元にある状態から始められるようになりました。
成果物の形として工夫しているのが、「そのまま投稿フォームに貼れる形式で記事タイトル案を出してもらう」という受け渡し設計 です。
レポートの末尾に「次の作業へそのまま渡せるコピー欄」を設けて、提案から実行へのバトンをコピペ一発で受け取れるようにしています。
制約として「既存記事を大幅に書き換えることは提案しない」「収益化についての提案は出さない」と明記しておくと、届く改善案が「すぐ試せる軽いもの」に自然と絞られるのも発見でした。
市場信号の取り込み｜ストック画像の反応追跡
自作のストック画像について、外部からの売れ行きを観察して「生成の方向性チューニング案」 を出してもらうタスクも仕込んでいます。
このタスクのポイントは「自分の好みの補強」ではなく、「自分の好み」と「外の評価」を意図的に別軸として分離する ところにあります。
制作者は自分の好みに引っ張られがちで、市場が何を求めているかは案外見えていないものです。
AIが外から観察したデータで「こういう傾向が売れやすそう」と提案してくれることで、自分の主観と客観的なシグナルを並べて意思決定できるようになりました。
制約には「未体験のレビューや主観的な評価は出さない」を明記しています。
主観と客観を分離することで、意思決定の根拠が一本増える という感覚が、このタスクを続けている理由です。
技術監視と提案｜コード品質の継続チェック
コード系のタスクは2パターンあって、どちらも「発見と実行の完全な分離」を設計の核にしています。
パターンA：技術サイトの改善提案と文章の間違い探し
別の技術サイトについて、コードは読むだけで直さず、「気づきと、あとで貼るだけの修正指示文」 だけを出してもらうタスクです。
「コードを勝手に変更しない」という制約を一行目に書くことで、AIは観察者・提案者としての役割に徹してくれます。
届くのは「ここがおかしい」という指摘と「直すならこう書けばいい」という指示文のセットなので、私がそれを読んで判断して、手を動かすかどうかを決めるだけ。
確認と実行のステップが完全に分かれるため、うっかり取り返しのつかない変更をしてしまう心配がなくなりました。
パターンB：デッドコードの掃除候補を洗い出す
複数のリポジトリを横断して「使われていないコードの候補一覧」 をレポート化してもらうタスクも動かしています。
「消すのは人間が確認してから」という前提は変わらず、AIはあくまで候補の列挙まで担います。
擬似コードで書くとタスクの骨格はこのようなイメージです。
// 擬似コード：デッドコード洗い出しタスクの骨格
対象リポジトリ = ["repo-a", "repo-b", "repo-c"]
for each repo in 対象リポジトリ:
候補リスト = 関数/変数の参照チェック(repo)
レポートに追記(repo名, 候補リスト)
// 省略（制約チェック・フォールバック取得等）
出力 = "削除候補一覧（確認待ち）"
// ※ 実際の削除は人間が手動で行うこのアウトプットがあるだけで、「なんとなく古そう」という感覚論ではなく、具体的な候補を見ながら整理できるようになります。
2つのパターンに共通するのが 「巡回→評価→レポート＋修正指示文」というテンプレート骨格 で、対象が変わっても同じ型を使い回せるのが大きな発見でした。
定時化を続ける、共通の設計
5つのタスクを並べてみると、設計が似ているものがいくつかあります。
これは偶然ではなく、同じ型をそのまま別の対象に転用した結果 です。
型ができると次のタスクを作るコストが一気に下がるので、「また似たようなやつを作った」という感覚は前向きに捉えています。
ここでは、5つに共通して効いている設計をまとめておきます。
成果物は自己完結のレポート1枚
どのタスクも、届いたレポートを開いた瞬間に全てが分かる構成にしています。
チャット履歴を遡って文脈を拾い直す手間 がなくなるだけで、毎朝の認知コストが大幅に下がりました。
「やってはいけないこと」を先に宣言する
各タスクには必ず「やってはいけないこと」を明記しています。
「勝手に実行しない」「未体験のレビューは出さない」「既存記事を大幅書き換えしない」「コードを勝手に削除しない」といった制約が先にあることで、AIが提案者の役割に自然と収まってくれる のを実感しています。
「対応済み」メモで繰り返し提案を防ぐ
一度対処した課題について「もう対応済みなので再提案不要」という現状メモをタスクに持たせています。
同じ提案が毎日届く状態 は、レポートへの信頼感を地味に削っていくので、このメモの仕組みは地味に重要です。
多段フォールバックで取りこぼしを減らす
情報取得は「通常取得→ブラウザ越し→検索」の順でフォールバックする設計にしています。
一つの手段が失敗してもレポートが空になりにくくなり、毎日安定して届く安心感 につながっています。
最後に
5つの活用例に共通するのは、AIに「見張り役と提案者」の役割を与え、「実行者と最終判断者」は人間が担うという設計です。
完全自動化ではなく「相棒化」という表現の方が、この運用には近いかもしれません。
「やってはいけないこと」を先に決めてしまえば、同じ型を別の場所に増やすのは一気に楽になるという発見は、ぜひ試してみてほしいところ。
現時点では手動キックが中心ですが、この設計があることで「次のタスクを作ろう」という気持ちが自然と湧いてくるのが、毎日続いている一番の理由かもしれません。
以上です。
コメントを残す