おはようございます。朝7時、いかがお過ごしでしょうか。4月12日、日曜日の朝です。「zenncast」パーソナリティのマイクです。
この番組は、技術情報プラットフォームZennで話題になっている記事を、朝のコーヒー片手にさらっとキャッチアップしていこう、というゆるっとテックなラジオでございます。今日もZennのトレンドから、気になる記事をピックアップしてご紹介していきます。
今日は全部で5本、ご紹介していきますね。AI活用、設計ノウハウ、タスク管理、そして最新のAIプラットフォーム活用まで、割とガッツリめのラインナップです。通勤・通学のおともに、ながら聞きでどうぞ。
まず1本目。タイトルは「Claude Code + Obsidian — Daily Note の下書きを自動生成し、週次・月次レビューまで積み上げる仕組みを作った」。
これはですね、「日報を書くのがしんどい」「週次レビューが続かない」っていう人ほど刺さりそうな内容でした。著者の方は、Obsidianのデイリーノートを「仕事のすべての記録のハブ」にして、その“下ごしらえ”をClaude Codeでガッツリ自動化しています。
面白いのが、いろんなサービスから情報を引っ張ってきてるところなんですよね。たとえばNotionとGoogleカレンダーからは、その日のタスクと予定を自動で拾ってきて、Daily NoteにTODOとMeetingのセクションを生成。Webクリッパーで保存した技術記事は、Claudeのスキルで要約して、クリッピングに追記してくれる。さらにSlack、GitHub、Notionのログから「今日やったこと」のサマリと次のアクション、そしてAIからのフィードバックまで自動生成してくれるという、かなり“パーソナルな業務ダッシュボード”になってます。
でもポイントは、「AIの出力を鵜呑みにしない」ってところなんですよね。あくまで叩き台として出してもらって、それを人間の自分が手で直すことで、「自分の言葉」「自分の反省」に落とし込んでいく。このプロセスがあるからこそ、日次だけじゃなくて、週次・月次のレビューにもちゃんとつながっていく。Weekly Reviewでは半期目標との整合性や、定量指標、それからちょっと厳しめのフィードバックまでスキルで出して、それをもとに「じゃあ来週どう動く？」って考える。最後は月次レポートとしてまとめて、長期の振り返りにしていく。
さらに、この仕組みを個人だけじゃなく、メンバー評価にも応用しているのも興味深かったです。Daily Noteを「日報」じゃなくて、「行動改善のためのデータ基盤」として育てていく。そのためのAIとMCPの使い方が、かなり実践的にまとまっている記事でした。
。。.。。.。.
続いて2本目。タイトルは「DESIGN.md + 壊れたら気づくハーネス - AI向けデザインシステムを「維持できる仕組み」にした記録」。
これは、TailwindベースのAI向けデザインシステム「melta UI」を、AIが長期間ちゃんと使い続けられるようにするための「運用設計」の話です。もともとはCLAUDE.mdという1枚岩のドキュメントに全部盛りしていたところから、「DESIGN.md」「contracts」「harness」という3層構造に作り替えた、その試行錯誤が語られています。
面白いのは、「生成品質を上げること」ではなくて「半年後に品質が落ちないようにすること」が目的だ、とはっきり言っているところ。現場っぽくていいですよね。課題として挙げられていたのが、禁止ルールがいろんなところに散らばってしまうこと、Markdownの説明と実際のJSONデータの数がズレていく“ドリフト”、そして複数ファイルを手で直すことで整合性が壊れていく問題。
これに対して、コンポーネントと禁止ルールをJSONで一元管理して、「ここが唯一の真実（Single Source of Truth）」という状態にします。その上でスクリプトとCIを用意して、スキーマの検証、参照チェック、件数のドリフト検出、さらに「AIがルール違反をしてないか」をリアルタイムで検出するハーネスを構築している。要は「仕様書をきれいに書く」のではなく、「壊れたらアラートが鳴る仕組み」をつくる、という思想ですね。
実践ステップも具体的で、まずはDESIGN.mdを作って思想と原則を書く。CLAUDE.mdは作業手順に限定して、役割をはっきり分ける。その次に、禁止ルールをJSON化して一元管理。最後に、ドキュメントに書かれているコンポーネント数と、実データの件数を突き合わせる簡単なスクリプトからでいいので、ドリフト検出を始めてみる。こういう「小さく始められるやり方」が提示されているのもありがたいです。
結論として、「良い仕様書があること」より、「壊れたときに気づける検証の仕組みがあること」が、スコアを上げるというより“スコアを下げない”ための鍵になる、というメッセージが印象的でした。AI向けのデザインシステムやプロンプトリポジトリを運用している人には、かなり刺さる内容だと思います。
。。.。。.。.
3本目。タイトルは「GitHub Copilot CLI で個人タスク管理をやってみる」。
これは、GitHub IssuesとProjectsを土台にして、GitHub Copilot CLIと自然言語でやりとりしながらタスク管理する仕組みを紹介した記事です。タスク管理ツール迷子の人、ちょっと耳を傾けてみてください。
設計としてはシンプルで、「達成したい目標」を`goal`ラベルのIssue、「具体的な作業」を`task`ラベルのIssueとして管理します。TaskはGoalのsub-issueとして紐づけて、進捗はGitHub ProjectsのStatus、Todo / In Progress / Doneで管理する、という形ですね。
ポイントは、`gh` CLIとPowerShellスクリプト、そして`.github/copilot-instructions.md`を組み合わせて、Copilotにこの運用ルールをちゃんと理解させているところ。ラベルの意味、IssueやProjectの使い方、GraphQL API経由で呼べるスクリプト一覧などを明文化しておくことで、Copilot CLIに「こういう風にタスクを作って・一覧して・紐づけて・ステータス変更してね」と頼めるようになっています。
結果として、ターミナル上でCopilotに自然言語で話しかけるだけで、たとえば「来週までにやりたいReactの勉強タスクを3つ作って」とか、「進行中のタスクを一覧して、終わったものはDoneに移動して」といった指示を、そのままGitHub上のIssue/Project操作に変換してくれる。`#`でのIssue絞り込みとも組み合わせられるので、既存のタスクを見つけるのも楽になっています。
個人的にグッときたのは、「こういう仕組み自体を、Copilotと対話しながら設計していくのが有効だった」という締めの一言ですね。ルールを文章化して、スクリプトを用意して、Copilotに試してもらって、うまくいかなかったら修正する。そのプロセスごと、GitHubリポジトリに公開されているので、自分のタスク管理に持ち込みたい方は参考になりそうです。
。。.。。.。.
4本目は「Claude Managed Agents を試してみた」。
Anthropicの新機能「Claude Managed Agents」を、実際に触ってみた体験記です。名前だけ聞くとふんわりしてますが、要はAnthropic側がホストしているコンテナ環境の中で、bash叩いたり、ファイル操作したり、コード実行したり、GitHubリポジトリをマウントしたりしながら、AIエージェントが自律的にタスクを進められるようにした仕組みですね。
この記事では、GitHubのWebhookからCloudflare Workers経由でDiscordに通知を飛ばす構成を組んでいて、その中で「Pull RequestはManaged Agentsにコードレビューしてもらう」「Issueやコメントは通常のClaude APIで要約して通知する」というワークフローを作っています。実際の設計では、「エージェント」と「セッション」を分けるのがポイントで、エージェントは“設定の塊”、セッションは“実行インスタンス”として扱うイメージですね。
面白かったのは、GitHubリポジトリをコンテナにマウントして、その中でレビューさせる流れの具体的な話と、ハマりどころとして課金エラーのトラブルシュートが書かれていたところ。セッションイベントをちゃんと見ていくと原因が分かる、というのは、これから触る人にはありがたい知見です。
一方で、スケジュールタスクとか、他のエージェント機構との“住み分け”はまだ手探りなところもありそうで、コスト面やユースケース設計の難しさも率直に語られていました。それでも、チーム開発での長時間タスク、たとえば大規模リポジトリの継続的なレビューとか、定期的なメンテナンス作業にはかなり有望なんじゃないか、という感触で締められています。「ちょっと触ってみるだけでも世界観が分かるので、一度試してみては？」という温度感でした。
。。.。。.。.
そして最後、5本目。タイトルは「GitHub Copilot SDKを使えばユーザーのサブスクを使ってAIサービスが作れるのでは…？」。
これは、「AIサービスを作りたいけど、LLMの課金管理が面倒でつらい」という開発者の悩みに、一つの回答を出している記事です。筆者は、GitHub Copilot SDKを使えば、「ユーザー自身が契約しているCopilotサブスクリプションを、そのままAIサービス側のLLM呼び出しに使えるのでは？」と気づいて、実際に「Route Atlas」というサービスを作って検証しています。
Route Atlasは、GitHubリポジトリのフロントエンドコードをCopilotに解析してもらって、画面一覧や状態バリエーション、画面遷移をグラフで可視化するWebサービスです。技術スタックとしては、フロントにAngular + Cytoscape.js、バックエンドにHono / Node.js、インフラはCloud Run。GitHub OAuthで取得したトークンを、Copilot SDKとGitHub APIの両方に使うことで、ユーザーのリポジトリアクセスとLLM呼び出しをまとめて扱えるようにしています。
解析は一発で終わらせるのではなく、複数ターンに分けて進めていくスタイル。まずフレームワークを自動検出して、ルーティング関連のファイルを特定し、そこから画面の状態や遷移を抽出していく。処理は非同期のジョブとして実行して、API経由で進捗を問い合わせられるようになっているのも実用的です。
さらに、Copilot SDK呼び出し部分はLLMAdapterとして抽象化してあって、将来的に別のモデルに差し替えたり、テストしやすくしたりできる設計になっているのもポイントでした。結果として、「開発者がLLM利用料を負担しなくても、ユーザーが自分のサブスクを使って高度なAI機能を利用できる」アーキテクチャの具体的な例になっています。個人開発者や小さなチームが、LLMコストをあまり気にせずにAIサービスを提供するための、一つの有力なパターンとして参考になる内容でした。
。。.。。.。.
というわけで、きょうのzenncastは、AIを使った日々の業務ログの自動化から、デザインシステムの“壊れたら気づく”運用、Copilot CLIによるタスク管理、Claude Managed Agentsの実践レビュー、そしてCopilot SDKを活用した「ユーザー課金で動くAIサービス」の事例まで、5本まとめてお届けしました。
気になる記事があった方は、ぜひショーノートから元の記事もチェックしてみてください。今日の放送で触れたポイント以外にも、設定ファイルの工夫や、実際の運用ノウハウ、ハマりどころなんかが、もっと詳しく書かれています。
この番組「zenncast」では、感想や「こんなテーマを取り上げてほしい」といったリクエストもお待ちしています。普段どんなふうにZennを活用しているか、AIや開発ツールとの付き合い方なども、ぜひ教えてください。
それでは、4月12日、日曜日の朝、そろそろお別れの時間です。今日も一日、良いアウトプットと学びがありますように。お相手はマイクでした。また次回のzenncastでお会いしましょう。