※この記事は、2026年6月時点の自分のAI運用メモです。
AIにツールを作らせたいと思うことが増えています。
ブログ整理もそうです。
Obsidianのinbox整理もそうです。
ちょっとした検証用の表や、判断補助の仕組みもそうです。
ただ、最近あらためて感じたのは、AIに「ツールを作って」と頼む前に、先に決めるべきことがあるということです。
それは、入力と出力です。
何を渡すのか。
何を返してほしいのか。
どこから先は人間が見るのか。
どの状態なら本体に組み込まず、検証版のまま止めるのか。
このあたりを決めないままAIに頼むと、思ったより大きい話になりやすいです。
今回は、その話を書いておきます。
いきなり本体に組み込もうとすると重くなる
AIに何かを作ってもらう時、つい最初から完成形を頼みたくなります。
既存ツールに機能を足したい。
データを自動で取ってきたい。
条件を判定してほしい。
一覧にしてほしい。
できれば、そのまま本番運用に入れたい。
気持ちはかなり分かります。
せっかくAIに頼むなら、手作業を減らしたい。
何度も同じ入力をしたくない。
できれば一発で使える形にしてほしい。
ただ、実際にやろうとすると、この頼み方はかなり重いです。
既存ツールに直接組み込むとなると、今動いている部分を壊さない必要があります。
自動取得まで含めるなら、取得元の仕様や規約、更新頻度も見ないといけません。
判定まで任せるなら、何を条件一致とするのか、何を要確認とするのかも決める必要があります。
つまり、「ツールを作って」の中に、いろいろな未決定事項が混ざってしまいます。
この状態でAIに頼むと、出てきたものを見ても、自分が何を確認すればいいのか分かりにくくなります。
コードが悪いのか。
条件が悪いのか。
入力データが悪いのか。
そもそも作ろうとしている形が大きすぎるのか。
そこが混ざると、修正も重くなります。
先に決めるのは、何を渡して何を返すか
最近は、最初に決めるべきなのは機能名ではなく、入力と出力だと思うようになりました。
たとえば、入力は何か。
手元のCSVなのか。
メモなのか。
スクリーンショットなのか。
HTMLなのか。
手入力した数行のデータなのか。
次に、出力は何か。
候補リストがほしいのか。
理由つきの一覧がほしいのか。
要確認ポイントだけ出してほしいのか。
危険そうなものを除外してほしいのか。
次に見る場所を教えてほしいのか。
この2つを先に決めるだけで、AIに頼む内容はかなり小さくなります。
「既存ツールにいい感じに組み込んで」ではなく、
「このCSVを読んで、条件に合いそうな行を理由つきで一覧化して」
の方が頼みやすい。
「全部自動で判定して」ではなく、
「条件一致、要確認、保留、除外の4つでラベルを付けて」
の方が確認しやすい。
AIはかなりいろいろできます。
でも、何を材料として渡すのか。
何を成果物として返すのか。
その境界は、人間側で決めた方がいい。
ここを曖昧にすると、AIはそれっぽく広げてくれます。
それは便利な時もありますが、ツール作りでは怖いところでもあります。
小さい検証版なら、失敗しても本体を汚さない
入力と出力を決めたら、次はいきなり本体に入れず、小さい検証版として作る方が扱いやすいです。
ここで言う検証版は、立派なアプリでなくてもいいと思っています。
CSVを読み込むだけの小さいスクリプト。
メモを貼ったら表にするだけの処理。
数件のサンプルだけで判定する試作品。
本体とは別に置いた、一回使い捨てでもいいツール。
このくらいで十分です。
むしろ最初は、その方がいい。
なぜなら、検証したいのは完成度ではなく、考え方だからです。
この入力で足りるのか。
この出力なら自分が確認できるのか。
このラベル分けで迷わないのか。
AIの判定理由は読める形になっているのか。
本当に本体へ入れる価値があるのか。
ここを見たいだけなら、大きな仕組みにする必要はありません。
小さい検証版なら、失敗しても捨てやすいです。
条件が悪かったら変えればいい。
入力が足りなかったら項目を増やせばいい。
出力が読みにくかったら表の形を変えればいい。
そもそも不要だと分かれば、本体に入れずに終われます。
これはかなり大事です。
本体に入れてから「やっぱり違った」となると、戻すのが面倒です。
でも、別の検証版なら、失敗そのものが確認材料になります。
AIに頼む時の言い方も変わる
入力と出力を決めると、AIへの頼み方も変わります。
以前なら、こう言いたくなります。
「このツールに新機能を追加して」
でも、これだとかなり大きいです。
最近なら、もう少し小さく頼みます。
「まず本体には組み込まず、別ファイルで検証版を作ってください」
「入力はCSVです」
「出力は候補、理由、確認ポイントの表にしてください」
「判定は、条件一致、要確認、保留、除外に分けてください」
「自動取得はまだ不要です」
「本体への統合は、何度か使ってから判断します」
こうすると、AIも動きやすいです。
自分も確認しやすいです。
特に大事なのは、「今回はやらないこと」も決めることです。
自動取得はしない。
本体へ組み込まない。
完全自動判定にはしない。
人間確認の余地を残す。
これを先に置いておくと、話が広がりすぎません。
AIに頼む時は、やることだけでなく、やらないことも渡した方がいいのだと思います。
「AIに任せる単位」とは少し違う話
この話は、以前書いた「AIに任せる単位」の話と近いです。
ただ、今回は少し違います。
AIに任せる単位の話は、作業をどう切るかでした。
今日はinboxを整理する。
今日は下書きを作る。
今日は関連記事だけ見る。
今日はWordPress用のHTMLにする。
そういう作業分解の話です。
今回の話は、ツールを作る前の設計に近いです。
何を入力にするか。
何を出力にするか。
どんなラベルで返すか。
どこから先を本体に入れないか。
作業を渡す前に、ツールとしての境界を決める話です。
ここを決めておくと、AIに頼む内容がかなり安定します。
逆にここが曖昧なままだと、AIが便利そうなものを作ってくれても、自分の運用に入れにくいことがあります。
最初から完成形を頼まなくていい
AIを使っていると、どうしても「どこまで任せられるか」を試したくなります。
それ自体は悪くないと思います。
ただ、ツール作りに関しては、最初から完成形を頼まなくてもいい。
むしろ最初は、
- 手元のデータを渡す
- 小さい検証版を作る
- 出力を見て確認する
- 条件を直す
- 何度か使う
- 本当に必要なら本体へ入れる
このくらいの順番でいいのだと思います。
AIに頼む前に入力と出力を決める。
それだけで、作るものの輪郭がかなりはっきりします。
そして、輪郭がはっきりしたものはAIにも渡しやすい。
自分も確認しやすい。
失敗した時も、どこが悪かったのか見えやすい。
最近は、AIにツールを作らせる力というのは、プロンプトを上手く書く力だけではないと感じています。
何を渡して、何を返してもらうか。
どこまでを検証版にして、どこから先を本体に入れるか。
その境界を先に決めることも、かなり大事なAI活用力なのだと思います。
コメント