noteを100本毎日公開して分かった、AI活用の本当の落とし所

しごとを楽にするノート

2026年5月29日 12:02

100本目を書き終えて、ふと最初の1本を読み返してみました。

書いてあったのは「AIを広めたいなら、教える前に触る理由を作る」。3か月後の自分が、まだ同じことを別の言葉で書いていました。

100本書く前は、もう少し派手な発見があると思っていました。新しいツールの紹介や、効いた技の話が増えていくはずだ、と。

実際は逆でした。100本書いて見えてきたのは、目新しい技術の話ではありません。むしろ、最初から書いていたことの輪郭が、だんだんはっきりしてきただけでした。

この記事では、その輪郭を「3つの落とし所」として整理します。AI活用が現場で残るかどうかを分ける、地味な境目の話です。100本書いてようやく言葉にできた、本当のところを残しておきたいと思います。

落とし所その1：「AIで何ができるか」より「人が何をやめるか」を先に決める

最初の落とし所は、出発点の置き方です。

AIを入れようとするとき、つい「これで何ができるか」から考え始めます。生成、要約、分類、自動化。並べると無限に思えますし、便利そうに見えるんです。

ところが、現場で残ったのは、機能を増やした側ではなく、業務を減らした側でした。

1本目に書いた「社内AIが広まらない本当の理由：教える前に『触る理由』を作る」は、社内で研修を続けても定着しなかった経験から書いた記事です。原因は教え方ではなく、AIで何をやめていいかが共有されていなかったことでした。「これを使えば、明日からこの作業をやらなくていい」と一行で言える状態を先に作らないと、ツールはずっと「便利そうな道具」のまま終わってしまいます。

46本目の「Copilotのライセンスが降りたのに使われなかった本当の理由」も同じ構造でした。ライセンスが配られても、業務のどこを差し替えていいかが決まっていなかった。結果、使われたのは検索代わりだけでした。

74本目では、月次の利用明細を毎月30〜40件、目視で数えていた作業を半自動化しました。最初は「全部AIに任せる」を考えていて、ログイン認証の自動化や保存先の自動判定まで盛り込もうとしたんですが、調べているうちに半月が経っていました。結局、ログインだけは人がやる、件数のカウントと保存だけを機械にやらせる、と分けました。これで初めて、月次の自動化が途中で止まらずに続いたんです。

すべて自動化しようとして遠回りする、という失敗パターンが、100本のあちこちに繰り返し出てきます。器を先に作り、機能を盛り、最後に「使われない」と気づく。「使われない」と気づいた頃には、もう作り直す気力が残っていません。

順番を入れ替えるだけでよかったんです。「人が何をやめるか」を先に1〜2個決めて、その分だけAIに肩代わりさせる。3時間かけていた集計が15分になる、週5件来ていた同じ質問が2件になる、その種類の変化が起きたときに、ようやくツールは現場に残ります。

数字は小さくていい。むしろ、最初は小さい方がいいです。大きく変えようとすると、現場の慣れまで一緒に動かす必要が出てきて、そこで失敗します。小さく1作業だけ消して、それが定着してから次の作業を消す。100本書いて、これだけは確信に変わりました。

機能を増やしたから使われるのではない。やめた作業の分だけ、AIは席を持てるんです。

落とし所その2：「精度を上げる」より「使われる時間帯を決める」

二つ目の落とし所は、技術的な完成度と運用の関係です。

PoCを作って、デモを見せて、「すごいですね」で終わる。これを何度繰り返したか分かりません。原因は精度が足りないからだと思い込んでいました。

そう思い込んでいる間は、ずっとプロンプトを書き直していました。書き直しても、現場で使われる回数は増えませんでした。

11本目の「Difyで作る、書類読み取りアプリの失敗しやすいポイント全部のせ」は、その典型でした。書類のフォーマットが少し変わるだけで、抽出結果が崩れる。列名が違う、表が分かれている、見出しの位置が違う、それだけで結果は手戻りの多いものになりました。精度を上げようとして、1か月くらいプロンプトを書き直し続けました。完全に頭打ちでした。

85本目で答えが出ました。精度を上げるのをやめて、「ここだけは人が確認する」と1項目だけ決めた瞬間に、現場で使われ始めたんです。

100点に近づけるためのチューニングをしていた間、現場の人は結局すべての項目を疑って二度読みしていました。アプリがあってもなくても、手間が大きく変わりません。「ここだけ見てくれればいい」が決まった瞬間、二度読みが1か所の確認に変わりました。

この経験で気づいたのは、精度のチューニングは「人が確認する場所をなくす」方向の作業で、運用設計は「人が確認する場所を決める」方向の作業だ、ということでした。向きが逆だったんです。逆方向に走り続けていたから、いくら精度を上げても現場の負担が減らなかった。

76本目の「倉庫の判断アプリで『LLM全部入り』をやめた本当の理由」も同じでした。判断のすべてをLLMに任せようとしていたのを、ルールで決まる部分はルールに戻し、迷う1点だけをLLMに渡す形に変えました。精度ではなく、運用の入り口を狭く設計したわけです。

60本目の「ローカルLLMが『遅くて使えない』本当の理由」も、技術的には確かに遅かったです。ただ、8GBのPCで朝の数分間だけ使う、という時間帯の決め方をすると、遅さはほとんど気にならなくなります。朝、コーヒーを淹れている間に走らせておけば、戻ってきたときには結果がそこにある。「遅い」は時間帯設計で消える種類の問題でした。

これは「精度を諦めろ」という話ではありません。精度より先に、いつ・どこで・誰がそれを使うかを決める方が、AI活用は早く現場に乗る、という順番の話です。

順番を間違えると、精度を上げ続ける1か月が、まるごと無駄になります。先に運用の入り口を決めておけば、その入り口に合うだけの精度を作ればよくなる。やるべき調整の量が、桁で違ってきます。

完成度は、使われ始めてから上げればいいんです。使われない完成度は、ただの設定ファイルでしかありません。

落とし所その3：「アプリを作る」より「運用を回す仕組みを作る」

三つ目は、100本書いてみて一番想定外だった落とし所です。

最初は、AI活用の学びは「アプリを作る数」と「使われる頻度」で測れると思っていました。ところが、100日続けて分かったのは、それより手前に「仕組みを回す」という学びの層がある、ということでした。

毎日記事を1本公開する、という運用を100日続けたのは、文章力でも気合いでもありません。続いた理由は、運用そのものを工程に分解して、別々の仕組みに任せたからです。

具体的には、AIに下書きを任せる工程、文体を整える工程、公開を回す工程を、別の役割として切り分けました。それぞれを Claude Code の「スキル機能」（特定の用途に特化させた小さな仕組み）で持たせて、自分の判断は「下書きを通すか」「題材を選ぶか」の2つに絞りました。さらに、公開時刻のスケジュール管理を別の仕組みに任せて、「いつ出すか」を毎日考えるのもやめました。

切り分けるまでは、1本を書くのに毎回ゼロから考えていて、3日に1度は「今日は無理かもしれない」と思っていました。題材を選ぶ、構成を考える、文体を整える、サムネを作る、公開時刻を決める。一つひとつは大した判断ではないのに、毎日それを全部やっていると、書く前に疲れてしまうんです。

切り分けたあとは、その判断がほとんど消えました。題材を選ぶ判断と、下書きを読んで通すかどうかの判断だけが残った。100本続いた本当の理由は、書く力ではなく、書かなくていい部分を仕組みに渡せたことでした。

途中、出来上がった記事の質よりも「出し続けられる仕組みになっているか」を実験対象にしていた時期もあります。当初は「PV稼ぎではないか」と自分でも疑っていましたが、振り返ると、毎日公開を回すための運用実験そのものが「運用を回す」学びの素材になっていた、と後から整理できました。

ここから分かったのは、AI活用の学びはアプリの数では測れない、ということでした。アプリは作って終われますが、運用は回し続けないと意味を持ちません。回し続けるための仕組みを作ることが、結果的に一番AIの使い方を学ばせてくれたんです。

この仕組みの中身は別記事に書きました。下書き・文体・公開を回す仕組み群とスケジュール運用をどう組み合わせて100日を維持したかは、note099（総括2）にまとめてあります。

成果物の数を増やす前に、それを継続的に生み出す仕組みを作る。回り道に見えて、ここが一番効きました。

100本書いて変わらなかったこと：「設計の順番」という型

ここまで3つの落とし所を書きましたが、振り返ると、すべての記事に共通する形があります。

「順番を間違えた → 正しい順番はこれ」という構造です。

データを整える前に、ダッシュボードを作らない（3本目）
通知を作る前に、見える化を先にやる（7本目）
アプリを作る前に、スキル機能で運用を回す（17本目）
追跡できないなら、傾向を掴むに切り替える（21本目）

100本を通じて、技術や題材は変わりましたが、この「順番」の型だけは変わりませんでした。1本目も100本目も、同じことを別の言葉で書いています。

これは、新しいことを学んだようでいて、実は最初から一つのことしか言っていない、という発見でもありました。最初は不安でしたが、書きながら気づきました。一つのことを100通りに言い換えられるなら、それは自分の核として持っていていいものだ、と。

もう一つ、100本書いて分かったのは、自分の核は「試して失敗して、その構造を分解して語る」というところにある、ということでした。

100本のうち、成功事例だけを切り出した記事はありません。どの記事にも、最初は失敗した、思っていたのと違った、という入り口があります。それを通して「だから次はこの順番でやる」と書いている。失敗から逆算した順番だけが、現場で再現できる順番でした。

精度より継続性、完璧より運用。100本書いても、この軸はまったくぶれませんでした。むしろ、ぶれなかったからこそ100本続けられた、という気もしています。

これから100本読む人へ：明日から試せる一歩

100本を通して読むのは現実的ではないので、入り口だけ4本のマガジンに分けて整理しました。

判断書化マガジン：手順書ではなく、判断のメモを残す試み
ローカルLLMマガジン：8GBのPCで何ができ、何ができないか
現場運用マガジン：作ったあと、どう乗せて、どう続けるか
AI普及マガジン：社内でAIが広まらないときの、構造的な原因

読む順番に迷ったら、3つの落とし所と対応させて選ぶといいかもしれません。

マネージャー・経営企画の方は、落とし所1の関連記事から（人が何をやめるかの設計）
現場でAIを使う方は、落とし所2から（運用に乗せる距離の取り方）
DX推進・社内普及の方は、落とし所3から（運用を回す仕組みの作り方）