🔍 機械チェック1本を先に置いた——AIの出力を自動保存するとき、使う側には見えていなかった穴

ミシンで縫った服に、裏から1本だけ縫い目が飛んでいる箇所があったとします。

表からはきれいです。「検品済み」のタグもついています。

でも裏には穴がある。着た人が袖の解けた縫い目を持って戻ってきて、初めて気づきます。

AIの出力を自動で保存する仕組みを初めて作ったとき、頭の中にあったのはこれでした。エラーが出ない。

画面には「完了」と表示されている。でも中身は静かに壊れていく。

あなたは今こうなっていませんか？

• AIの回答を「精度が高いから大丈夫」と、そのまま使っている • 自動で保存される仕組みを作ったが、エラーが出なければOKと思っている • 「AIが書いたなら正しいはず」と、確認をスキップしたことがある • 使う側から作る側になったとき、何が変わるのかまだ実感がない

先に結論を言います。

AIの出力を自動で保存するなら、機械的なチェックを1本置くだけで、「正しそうに見えて静かに壊れていく状態」を防げます。

この記事では、LLMに共有メモを書かせる仕組みを自分で作ったとき、なぜ正規表現チェックを最初に設計へ組み込んだのかを書きます。

CMO時代の前提と、実際に作る側になったときのギャップも合わせて話します。

CMO時代、私がAIの出力を信じていた前提

「精度が高ければ使える」という考え方

マーケターとして広告や企業PRを担当していた頃、AIツールへの信頼は「結果で判断するもの」でした。

月3,000万円規模の広告を運用していた時期も、AIが生成したコピーや分析レポートは「いい感じなら採用、おかしければ修正」で扱っていました。

案件数が増えるほど、AI出力を一つひとつ確認する時間は短くなっていきます。

「精度80%なら、残り20%だけ確認すればいい」という考え方は、忙しい時期には合理的に見えます。

でも実際には、その20%がどこにあるかを見分けることが、量が増えるほど難しくなります。

精度という数字は、個別の出力がどこで壊れているかを教えてくれません。

見分けられなかった部分が、確認されないまま静かに積み重なっていきます。

50人規模のチームでAI活用を推進していたときも、出力が「きれいに見えるかどうか」が主な判断軸でした。

きれいに見えるものは通して、見た目がおかしいものだけ差し戻す。

そのやり方が体に染みついていたので、「AIを信じる基準」は自分でも気づかないうちに固まっていました。

「精度が高い＝使える」という前提が、骨のように体の中に入り込んでいたんです。

使う側には「プロセスの中身」が見えない

使う側の立場では、届いた出力を評価するしかありません。

「このツールの結果を見て、使えるかどうかを判断する」は、日常的に合理的な選択です。

毎回仕組みの中身を調べるより、結果で判断した方が速いからです。

問題は、このパターンが「使う側の視点」に固定されると、作る側になったときも同じ感覚で設計してしまうことです。

「結果が出ればOK」という判断軸を、仕組みを作るときにもそのまま持ち込んでしまいます。

自動化した仕組みでは、結果が出たからといって、プロセスが安全だったことにはなりません。

これが、最初の設計で見落としていたことでした。

使う側は問題に「気づける立場」にあります。

でも自動化の目的は「人間が毎回確認しなくていいようにする」ことなので、気づくタイミング自体がなくなってしまいます。

「問題がない」と「問題に気づいていない」は、画面の表示の上では同じに見えます。

この区別を、設計の中に組み込んでおく必要があります。

📕 AIエージェントと自動化の全工程をまとめた総集編 手順・コード・テンプレをそのまま渡しています 🤖【完全版】月商160万円の「寝てても回る仕組み」をゼロから30日で組む全工程｜2026年10月版・Claude Code×AIエージェント・特典40ファイル・毎月更新

AIに共有メモを書かせる仕組みを作り始めた

「共有メモ」とはどういうものか

今の仕事では、AIが「共有メモ」を書いてくれる仕組みを使っています。

少し背景を説明します。AIのセッションは、基本的に毎回記憶がリセットされます。

「前回こういう判断をした」という文脈を、次のセッションに持ち越せないんです。

そこで、AIが仕事をするたびに「今日の判断と状況」をメモとして残して、次のセッションでそのメモを読み込む仕組みを作りました。

人間のチームで言うと、毎日書く引き継ぎノートのようなものです。

このメモが正確に書かれていれば、AIは前回の文脈を踏まえた判断ができます。

逆に、メモがおかしければ、AIは誤った文脈から動き始めます。

AIに「正しいメモを書いてもらう」ことの重要さを、作り始めた当初はあまり深く考えていませんでした。

「AIが書くんだから、大きくはずれないだろう」という前提が、ここでも顔を出していました。

最初の設計：「そのまま保存すればいい」と思っていた

仕組みを作り始めた頃、設計はとてもシンプルでした。

AIが書いた内容を、そのままファイルに追記する。エラーが出なければ保存完了。それだけです。

コードで書いてみたら、最初のバージョンはたった20行以内で動きました。

「AIが返してきた文字列をファイルに書き込む」という処理を、ほぼそのまま書いただけです。

このとき、私の頭の中はCMO時代と変わっていませんでした。

「AIが出力したんだから、おかしな形式にはならないだろう」という前提が、設計にそのまま入り込んでいました。

仕組みが動いている。ファイルが増えている。一見うまくいっているように見えます。

でも実際には、確認できないまま保存し続けていただけでした。

もし誰かに「その仕組み、安全ですか？」と聞かれたとき、答えられなかったと思います。

「動いてはいます」としか言えなかった。

最初の3日間で起きたこと

エラーが出ないから気づけない

仕組みを動かし始めてから3日後、保存されたメモを読み返してみました。

そこで気づいたのが、日付の書き方がバラバラになっていることでした。

「2025年10月」「2025-10」「10月」と、同じ月なのに3種類の書き方が混在していたんです。

プログラムはエラーを出していません。ファイルは正常に保存されています。

画面にも異常は表示されていません。

でも中身は、ゆっくりと壊れていました。これが「エラーが出ないのが怖い」という感覚の正体でした。

最初の日付を見たとき、「気にしすぎかな？」とも思いました。

でも読み進めると、2日目、3日目と少しずつ形式が変わっていることが分かってきます。

問題は小さなうちは目立ちません。

だから積み重なりやすいし、気づいたときには「全部読み返す」ことになります。

4つ目のメモで気づいたこと

具体的に「あ、これはまずい」と思ったのは、4つ目のメモを読み返したときでした。

日付の欄が「なし」になっていました。

AIが「この文脈では日付は必要ない」と判断して、フォーマットごと省略していたんです。

これはAIが「悪さをした」のではありません。

フォーマットを明示していなかったので、AIが自分なりに最適化した結果です。

ただ、私が期待していたフォーマットとは違う。そしてその違いは、エラーとして表示されません。

「あ、全部やり直しだ……」と頭が真っ白になりました、、、3日分のメモを手で読み返して、どこがおかしくなっているかを確認するのに1時間以上かかりました。

見直してみると、日付だけでなく、項目名の書き方も少しずつ変わっていました。

「次のアクション」と書いていたものが「次やること」になったり、「判断」が「結論」になったりしていたんです。

これ自体は意味が通じます。でも仕組みとして読み込む側からすると、別の項目になってしまいます。

フォーマットを決めておかないと、こういうことが静かに起きていくということを、このとき初めて実感しました。

AIに指示を出すとき、人間相手に話すような曖昧さを持ち込んでいたことに気づきました。

「いい感じに書いて」は人間には伝わっても、毎回同じ形式を保証しません。

人間同士のやりとりでは、文脈から補完してもらえます。

でも自動化された仕組みの中では、文脈で補完してもらうのではなく、形式を明示する必要があります。

これが「使う側の感覚」と「作る側の設計」のいちばん大きなずれだったと、今は思っています。

機械チェックを1本置く設計に変えた

正規表現チェックとは何か（難しくないです）

ここで少し説明を入れます。「正規表現チェック」という言葉が出てきますが、難しく考えなくて大丈夫です。

一言で言うと、「文字列がルール通りの形になっているかを確認する仕組み」です。

郵便番号が「123-4567」という形式になっているかを機械が自動で確かめるイメージです。

「2025-10-16」という形の日付が来たらOK、それ以外はNG、と機械が自動で判断します。

人間が目で見て「これは合ってる、これはおかしい」と確かめるのと同じことを、一瞬でやってくれます。

これを「保存する前」に挟むことで、想定外の形式のデータがファイルに入り込まなくなります。

コードが書けなくても、AIに「この形式以外では返さないで」と伝えるだけで、同じ効果を出せます。

「形が合っているかどうかを確かめる番人を、入り口に1人置く」イメージです。

難しい技術の話ではなく、設計の考え方の話です。

チェックを通ったものだけ反映するようにした

私が変えたのはここだけです。

AIが書いた内容を、すぐに保存するのではなく、正規表現チェックを通してから保存するようにしました。

チェックを通らなかった出力は、保存せずにログファイルに残して、後から確認できるようにしました。

追加したコードはたった10行以内でした。仕組みを作り直したわけではありません。

保存する前に「この形式でなければ通さない」という場所を1箇所だけ増やした。

それだけで、3日間の問題が起きなくなりました。

チェックを入れてから最初の1週間で、通らなかった出力が12回ありました。

チェックがなければ、12回分のおかしなメモが静かに積み重なっていたところです。

数字で見ると、1週間に12回というのはかなりの頻度です。

「AIなら大丈夫だろう」という感覚とのギャップが、はっきり見えた瞬間でした。

この経験から、『共有メモリを書くLLMは信用しない』という設計の考え方を、自分の中での正本として残すようになりました。

AIを信じないということではなく、「信じられる形にするための仕組みを先に置く」という意味です。

「信用しない」と書くと冷たく聞こえますが、実際はその逆です。

チェックを通じて「これは正しい」と確認できるから、安心して使えるようになります。

人間の書いた文書にも誤字はあります。でもレビューを経た文書には「確認した」という根拠がある。

それと同じ話です。

使う側と作る側で、信用の意味が変わった

使う側の信用：届いたものへの評価

CMO時代の私にとって、AIへの「信用」は結果から来ていました。

「このツールで書いたコピーは反応率が上がった」「この分析の精度は高かった」——そういう実績がAIへの信頼を作っていました。

これは合理的な判断の積み重ねです。

でも使う側は、プロセスの中身を見ません。「正しそうに見えるもの」が届いたとき、それを信用します。

チェックを入れていなければ、私もずっと気づけなかったと思います。

日付がバラバラのメモを受け取り続けても、エラーが出ない限り確認しません。

使う側の「信用できる」は、「今まで結果が出た」という過去の話です。

自動化した仕組みは、確認されないまま動き続けます。

作る側の信用：プロセスが安全かどうか

自分で仕組みを作る側になると、問いが変わります。

「この出力は正しいか」ではなく、「この仕組みは100回動かしても壊れないか」が問いになります。

出力1つへの評価ではなく、設計レベルの話です。

ここが使う側と決定的に違う点です。

使う側は届いたものを見て判断できますが、作る側は届く前の設計で判断しなければなりません。

「AIを信じる・信じない」より先に、「どこで止めるか」を仕組みの中に組み込む。

これが、自分で作る側になって初めて実感できたことでした。

使う側には見えていなかった穴が、作る側になって初めて見えてきます。

「使う側と作る側で信用の意味が変わる」というのは、こういうことだったんだと思っています。

チェックを入れてから変わった3つのこと

壊れた原因をすぐ特定できるようになった

正規表現チェックを入れてから、何かがおかしくなっても原因を探す時間が大幅に短くなりました。

以前は「どのメモがいつおかしくなったか」を手で読み返して確認するしかありませんでした。

今は、チェックを通らなかったログを見れば、「この日のこの出力が通らなかった」とすぐ分かります。

1時間以上かかっていた確認作業が、ログを確認する1分になりました。

毎日の積み重ねで考えると、この差はかなり大きいです。

仕組みが「自分で問題を報告してくれる」状態になった、という感覚があります。

チェックを入れる前は、問題が起きても仕組みが黙って先に進んでいました。

AIへの信頼度が上がった

逆説的に聞こえますが、チェックを入れてからの方がAIの出力を信頼できるようになりました。

「チェックを通ったから、少なくとも形式は正しい」という事実があるからです。

「多分大丈夫だろう」という感覚より、ずっと根拠のある信頼です。

人間のチームで言うと、レビューを経た資料と、書きっぱなしの資料の違いに似ています。

書いた人が同じでも、レビューを経た方を信頼できますよね。

チェックという仕組みが、信頼の根拠を作ってくれています。

AIを信じるかどうかの問題を、設計で解決できるということでもあります。

仕組みを育てやすくなった

チェックの基準を変えれば、仕組みの精度を上げられます。

最初は日付のフォーマットだけ確認していました。今は4種類のチェック項目があります。

問題が起きるたびにチェックを1つ増やすことで、仕組みが少しずつ強くなっていきます。

「壊れる→気づく→チェックを増やす→壊れにくくなる」というサイクルができました。

このサイクルが回るためには、「壊れたことに気づける仕組み」が必要です。

最初にチェックを入れたのは、このサイクルの起点を作るためでもありました。

広告費0円で仕組みを育てながら結果が出てきたのも、こういう地味な積み重ねがあったからだと思います。 Claude Code自律環境の仕組みの全体は有料記事にまとめていますので、興味がある方はフッターのリンクからどうぞ。

「作る側になる」ということ

設計とはどこで止めるかを決めること

「プログラミングができないと仕組みは作れない」というのは、少し違います。

もちろんコードが書けると自由度は高まります。

でも「どこで止めるか、どこを通すか」という判断は、コードを書く前にできることです。

「AIの出力をそのまま保存するのではなく、一度確認してから保存する」——これは設計の判断です。

コードを書く前に、頭の中で決められます。

私がこの仕組みに追加したのは、コードほぼ0行に近い量でした。

でも「どこで止めるか」を考えることに、一番時間を使いました。

設計の判断は、技術の問題ではなく視点の問題です。

「作る側の視点」を持てれば、仕組みを作ることへのハードルはずっと下がります。

CMO時代には思ってもいなかった感覚が、自分で仕組みを作るようになって出てきました。

使う側では見えていなかったものが、作る側になると見えてきます。

使う側にいる間は「仕組みを作る人が考えること」として切り離していました。

でも自分でゼロから組み始めると、その境界がなくなります。

使う人と作る人が同じになるとき、「信じて使う」だけでは成り立ちません。

「信じられる形にする設計」を自分で持つことになります。

今日から試せることが1つあります

もし今、AIの出力を自動で保存したり、自動で何かに使っている仕組みがあれば、1つだけ確認してみてください。

「この出力が想定外の形式で来たとき、仕組みはどう動くか？」

エラーが出るか、そのまま通るか、止まるか。一度見てみるだけです。

確認できたら、「想定外のときに止める場所」を1つだけ増やす。

それだけです。私の場合は確認したら、3日分の穴がありました。

解雇から半年、ゼロから仕組みを育ててきた中で、一番早く効いた学びが「機械チェックを先に置く」という習慣でした。

使う側から作る側に移るとき、最初に押さえておいてよかったと今も思っています。

機械チェックを1本置くだけで、仕組みは全然違うものになります。

AIを信じない、ということではなく、「信じられる形にする設計」を自分で持つということです。

タイトル: 🔍 機械チェック1本を先に置いた——AIの出力を自動保存するとき、使う側には見えていなかった穴

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順