※この記事は、2026年7月時点の自分のAI運用メモです。AIエージェントや自動化ツールの使い方は今後も変わると思うので、現時点の実感として読んでください。
最近、AIを使って小さい自動化や補助ツールを作る場面が増えてきました。
コードを書いてもらう。
動作確認をする。
レビュー用のスキルを作る。
既存のスクリプトを改善する。
作業ログを見ながら、次の改善点を考える。
こういう作業を続けていると、最初は「専門担当を増やせばいいのでは」と考えたくなります。
実装担当。
レビュー担当。
テスト担当。
改善案担当。
外部情報確認担当。
ログ整理担当。
たしかに、役割を分けると便利そうです。
ただ、実際に自動化系の作業を進めていると、別の問題が見えてきました。
専門担当を増やす前に、プログラム全体の改善要望を受ける入口が必要なのではないか、ということです。
ここで言っている総合窓口は、ブログ運用の話ではありません。
ブログは今のところ、一つのチャット内で下書き、修正、UP版まで進められています。必要になれば将来的に運用を分けることはあるかもしれませんが、今の主題ではありません。
今回考えているのは、自動化やプログラム改善の方です。
小さいツールやスキルが増えた時に、どの部分を直すのか、どの担当に渡すのか、先に何を確認するのかを受け止める入口が必要になる、という話です。
専門担当を増やしても、改善要望の置き場がないと迷う
自動化を作る時、最初は作業単位で考えます。
この処理を自動化したい。
このログを整理したい。
このファイルを読ませたい。
このスクリプトの動作を確認したい。
この出力をWordPress用に整えたい。
一つひとつは、それほど大きくありません。
だから、専用の担当を作る発想は自然です。
コードを書く担当。
レビューする担当。
テストする担当。
ログを見る担当。
改善案を出す担当。
でも、実際の改善要望は、きれいに一つの担当へ入るとは限りません。
たとえば、ある自動化を直したいと思った時、その原因がどこにあるのかは最初から分かりません。
仕様が曖昧なのか。
入力データの形が悪いのか。
実装が足りないのか。
テスト方法が悪いのか。
出力先が間違っているのか。
そもそも、その自動化を今やるべきではないのか。
ここを決める前に、いきなり実装担当へ渡すと、違う場所を直し始める可能性があります。
レビュー担当へ渡しても、どの観点で見ればいいのかが曖昧になります。
テスト担当へ渡しても、何を合格にすればいいのかが見えません。
専門担当が足りないというより、改善要望を最初に受ける場所が足りない。
そこが最近の違和感でした。
個別の自動化担当に全体設計まで持たせると、役割がぶれる
個別担当に、全体設計まで相談し始めると、だんだん役割が膨らみます。
たとえば、レビュー用のスキルに、次に作るべき自動化まで相談する。
ログ整理用の流れに、ツール全体の設計変更まで相談する。
実装担当に、仕様、優先順位、テスト方針、運用ルールまで決めさせる。
これは一見便利です。
でも、あとから見返すと、その担当が何のためにあるのか分かりにくくなります。
レビュー担当なのか。
仕様相談なのか。
設計変更なのか。
運用ルール作りなのか。
次の自動化候補の整理なのか。
全部を一つの担当に混ぜると、最初は楽でも、後から再利用しづらくなります。
自動化は、作って終わりではありません。
むしろ、使ったあとに直す部分が出てきます。
その時、どこへ改善要望を投げればいいのかが曖昧だと、毎回その場の会話で決めることになります。
だから、専門担当の上に巨大な万能AIを置きたいというより、専門担当へ渡す前の受付が必要なのだと思いました。
必要なのは万能AIではなく、改善要望の受付
ここで言う総合窓口は、何でも答える万能AIではありません。
完成品を一発で作るAIでもありません。
やってほしいのは、まず改善要望を受けて、次に進む場所を決めることです。
たとえば、こんな確認です。
- これは新機能なのか、既存機能の修正なのか
- これは仕様の問題なのか、実装の問題なのか
- これはテスト不足なのか、運用ルール不足なのか
- どのファイルやスキルが関係しているのか
- 先に再現条件を確認すべきか
- 人間が判断するべき条件は何か
- どの担当に渡すと一番ズレが少ないか
この段階では、まだコードを書かなくてもいいです。
むしろ、すぐにコードを書かない方がいい場面もあります。
改善要望の正体が分からないまま実装すると、違うものを作ってしまうからです。
まず要望を受ける。
分類する。
足りない前提を聞く。
関連するファイルやログを探す。
次に渡す担当を決める。
この入口があるだけで、自動化の改善はかなり進めやすくなる気がします。
Obsidianの共通メモリとは役割が違う
前回、複数AIを使い分けるなら、Obsidianを共通メモリにする方が自分には合っているという話を書きました。
あれは、文脈の置き場の話です。
どんな方針で運用しているのか。
どこまで作業が終わっているのか。
どのログをrawへ逃がしたのか。
どの候補をworkbenchで育てているのか。
どの判断をdecisionsへ置いたのか。
こうした文脈を、自分側に残す話でした。
今回の話は、その文脈を使って、自動化の改善要望をどこへ流すかを決める話です。
Obsidianが「記憶の置き場」なら、総合窓口は「改善要望の受付」です。
記憶があっても、受付がなければ、毎回人間が全部の振り分けを考えることになります。
逆に、受付だけあっても、過去の文脈がなければ、毎回同じ説明をし直すことになります。
だから、この二つは別の役割として考えた方がよさそうです。
Obsidianに文脈を置く。
総合窓口で改善要望を受ける。
必要な担当やスキルへ渡す。
結果をまたObsidianへ戻す。
この流れにできると、自動化を育てやすくなります。
改善相談の入口に持たせたい役割
今の自分が総合窓口に持たせたい役割は、大きく五つあります。
1. 改善要望を分類する
まず、要望の種類を分けたいです。
新機能なのか。
不具合修正なのか。
出力形式の変更なのか。
ログ整理なのか。
テスト追加なのか。
運用ルールの変更なのか。
使い方の整理なのか。
ここを最初に分けるだけで、次に渡す相手が変わります。
不具合なのに新機能として進めると、根本原因が残ります。
出力形式の問題なのにロジックを変えると、余計な修正になります。
運用ルールの問題なのにコードだけ直すと、また同じズレが出ます。
だから、改善相談の入口では、まず「これは何の問題か」を見たいです。
2. 関係する場所を探す
次に、どこを見ればよいかを探します。
スクリプト本体なのか。
設定ファイルなのか。
スキルの説明なのか。
過去の試行ログなのか。
dailyの作業記録なのか。
rawへ退避した会話なのか。
自動化が増えるほど、関係する場所も増えます。
人間が毎回思い出して指定するのは重いです。
総合窓口には、要望を見て「まずこのあたりを確認するのがよさそう」と案内してほしい。
それだけで、実装やレビューに入る前の探索が楽になります。
3. 先に確認する条件を出す
すぐ作業に入る前に、確認条件を出す役割も必要です。
再現条件はあるか。
入力例はあるか。
期待する出力は決まっているか。
既存の動作を壊してよいのか。
テストで確認できるのか。
失敗した時に戻せるのか。
このあたりが曖昧なまま実装すると、後で確認に戻ります。
AIにコードを書かせる時ほど、実装前の確認条件が大事になります。
総合窓口は、ここでいったん止める役割も持っていてほしいです。
4. どの担当へ渡すかを決める
分類と確認ができたら、次に担当を決めます。
実装担当に渡すのか。
レビュー用スキルに渡すのか。
テストを増やすのか。
ログを整理するのか。
仕様メモを作るのか。
人間に判断を戻すのか。
ここを総合窓口が提案してくれると、専門担当は自分の役割に集中できます。
実装担当は実装へ。
レビュー担当はレビューへ。
ログ整理担当は整理へ。
人間は最終判断へ。
専門担当を増やすなら、その前に担当選びの入口が必要です。
5. 作業後の戻し先を決める
最後に、作業結果の戻し先です。
コード変更なら、変更理由と検証結果を残す。
スキル改善なら、どのルールを足したか残す。
試行ログなら、成功、失敗、環境制約、次の改善を分ける。
記事候補ならworkbenchへ置く。
確定方針ならdecisionsへ置く。
ただ出力して終わりにすると、次に同じ問題が出た時に探せません。
自動化を育てるなら、改善結果をどこへ戻すかまで入口側で見ておきたいです。
ブログ運用は今すぐ総合窓口の対象ではない
今回の話で、ブログ運用を完全に外すわけではありません。
将来的には、ブログのネタ出し、下書き、UP版、関連記事、Instagram文面、リンク確認までを、より自動的に回す入口があってもよいと思います。
ただ、現時点ではブログ作業は一つのチャットでかなり回せています。
むしろ今困っているのは、自動化系のプログラムやスキルを改善する時です。
何かを作る。
試す。
うまくいかない。
原因を見る。
修正する。
レビューする。
次の運用へ戻す。
この流れの中で、改善要望がどこへ行くのかを決める入口がほしい。
だから、今回の総合窓口は、ブログ担当ではなく、自動化改善の受付として考えています。
ここを混ぜると、また役割がぼやけます。
まずは自動化系統の改善相談に絞った方がよさそうです。
まずは小さい受付から試す
いきなり大きな管理システムを作る必要はありません。
最初は、小さい受付で十分だと思います。
たとえば、改善要望を受けた時に、次の五つだけ確認する。
- これは新機能、修正、レビュー、テスト、運用ルールのどれか
- 関係するファイルやログはどこか
- 先に確認すべき条件は何か
- どの担当やスキルへ渡すべきか
- 作業後にどこへ記録するか
これだけでも、かなり違うはずです。
今の自分の運用では、毎回の会話の中でこれを何となくやっています。
でも、何となくやっている限り、チャットが変わるたびに揺れます。
改善相談の入口として明文化できれば、自動化やプログラム改善をもう少し安定して回せると思います。
まとめ
AIで自動化を進める時、専門担当を増やせば楽になると思っていました。
でも、実際にはその前に必要なものがありました。
改善要望を受ける入口です。
どこを直したいのか。
それは仕様なのか、実装なのか、テストなのか。
どのファイルやログを見るべきなのか。
どの担当へ渡すべきなのか。
作業後にどこへ戻すべきなのか。
ここを決めないまま専門担当を増やすと、担当は増えているのに、改善の流れは混ざっていきます。
万能AIではなく、受付のAI。
答えを出すAIではなく、改善要望を切り分けるAI。
ブログ運用の総合窓口ではなく、自動化系統のプログラム改善を受ける入口。
まずはそこから作る方が、自分のAI運用には合っている気がしています。
コメント