AIと人間で業務を回す仕組みづくり｜自社運用の事故と再発防止

パスワードを書きためたメモが、約2週間、誰でもアクセスできる状態で自社サイトの本番環境に置かれていた——これは他社の失敗談ではなく、AIで自社メディアを回している私たち自身が2026年に起こした事故です。しかも気づいたのは流出から2週間後。攻撃を受けたわけでも、難解なバグでもありません。追跡してはいけないはずのファイルが、AIに任せた公開の流れにそのまま乗ってしまっただけで、秘密は静かに世界へ出ていきました。

AI Lab OISHIでは、自社のブログ記事とX（旧Twitter）の投稿を、ネタ探しから執筆・事実確認・画像づくり・品質検査・予約公開まで、AIエージェントとその下で働くサブエージェントの集団に任せています。人間がやるのは、方針を決めること、公開のゴーサインを出すこと、最後に自分の目で見ること、そして間違いを直させることだけです。この記事は、その「AIと人間で回す編集部」の内側で実際に何が壊れ、それをどうやって二度と壊れない形に作り替えていったかを、包み隠さず公開する運用録です。AIをどう業務に組み込むかを探している実務者・経営者の方に、きれいな成功談ではなく、事故とその後始末という一番役に立つ部分をお届けします。

なぜ「AIに任せる」だけでは事故が止まらないのか

まず、私たちが何をどこまで自動化しているのかを整理します。中心にあるのは、9,000字を超えるブログ記事1本と、それに連動する4本のX投稿を、企画から予約公開まで一気通貫で組み上げる流れです。ネタを選び、執筆し、事実を確認し、図解や画像を作り、品質を検査し、指定時刻に無人で公開する——この一連を、AIエージェントとサブエージェントの分業でこなしています。記事はサーバー側で予約時刻に自動公開され、Xの投稿はサーバーに常駐した仕組みが決まった時刻に無人で配信します。

ここで多くの人が誤解しがちなのが、「賢いAIに任せれば品質も安全も勝手についてくる」という期待です。実際は逆でした。AIは驚くほど良い記事を書きますが、同じくらい平気で予想外のことをします。事実確認を甘くしたり、秘密を含むファイルを公開の流れに乗せたり、複数のAIを並べると全員が同じ言い回しに寄っていったり。賢さと安全は別物で、賢いAIほど、止める仕組みがないと事故のスケールも大きくなります。約5ヶ月で記事は約200本、Xの投稿は累計およそ590本まで積み上がりましたが、その裏で私たちが本当に投資したのは、名文を書かせる工夫ではなく、悪い出力を機械が自動で止める門の設計でした。

全体像をイメージとしては、下の図のように「6つの工程が直列に流れ、人間はたった2か所でだけ関与する」構造になっています。無人で流れる区間を長く取るほど楽になりますが、その分どこか1か所が壊れると全部が止まる、あるいは全部が事故になる。だからこそ、工程のつなぎ目ごとに機械の検査を置いています。

この構造を「1万6千を超えるコミットの約9割が機械による自動更新」という数字が裏づけています。コミットとは、変更を記録して保存する作業のこと。その9割がbot（自動プログラム）による定型更新で、人間が手で触っているのは全体のごく一部です。創作という人間らしい部分だけをAIとサブエージェントに任せ、採番・統合・集計・保存といった機械的な繰り返しは決定論的なスクリプトに固定する。この切り分けが、少人数でも毎日回し続けられる土台になっています。同じ「機械的な繰り返しはスクリプトに固定する」考え方を複数の自動化システムに広げて整理したAI自動化システムをまとめた記事もあわせて読むと、全体像がつかみやすいはずです。

人間とAIの線引き｜人間は「GOを出す人・見る人・直させる人」

自動化でいちばん大事なのは、実は技術ではなく「どこを人間が握るか」という線引きです。私たちの答えははっきりしています。人間は「書く人」をやめる。代わりに「方針を決める人・GOを出す人・最後に見る人・間違いを直させる人」に徹する。この4つ以外は、原則としてAIか無人の仕組みに渡します。

たとえるなら、これはテレビ局のプロデューサーと制作スタッフの関係のようなものです。プロデューサーは自分でカメラを回したり編集したりはしません。企画を通し、方向性を示し、完成した映像を試写でチェックし、直しを指示する。手を動かすのは現場のスタッフです。私たちの運用では、その現場スタッフがAIとサブエージェントの集団に置き換わっただけで、人間が担う「判断」の役割は昔ながらのプロデューサーとほとんど変わりません。

この線引きを守るために、私たちは「AIに作らせて回す運用者」という立場を徹底しています。つまり、自分でプログラムを書くのではなく、AIに指示して作らせ、動かなくなったらAIに直させる。これは引け目ではなく、役割分担をはっきりさせるための意図的な設計です。手を動かす主体がAIだと明確にしておくと、「人間がボトルネックにならない設計」に自然と寄っていきます。Xの投稿は現在、朝・昼・夜・深夜の4本を時間帯ごとに違う役割で配信していますが、これも人間が毎回ボタンを押すのではなく、作り置きした投稿を無人の仕組みが時刻どおりに出す形にしています。人間と機械の役割分担をもう少し初心者向けに噛み砕いたAI半自動化を7ステップで始めるガイドも、最初の一歩の参考になります。

事故で学ぶ①：秘密メモが本番Webで公開された

冒頭で触れた事故を、もう少し詳しく振り返ります。あるとき、パスワードを控えたメモ書きのファイルが、公開用の置き場所に紛れ込みました。私たちのサイトは「保存した内容がサーバー側に自動で反映される」仕組みで運用しています。push（変更をサーバーへ送る操作）をすると、数分ごとに走る仕組みがそれを拾って本番へ反映する。便利な一方で、この仕組みには落とし穴がありました。追跡対象に入れてはいけないファイルまで、いったん記録されてしまえば、そのまま本番Webへ流れ出るのです。

結果として、秘密を含むメモは約2週間、誰でもアクセスできる状態でネット上に存在していました。攻撃されたのではありません。私たち自身が、公開してはいけないものを公開の流れに乗せてしまった。ここで得た教訓を一言で言えば、「追跡した瞬間、それは本番公開への片道切符を手にしたようなもの」という現実です。頭では分かっていても、日々の作業のなかでは簡単に見落とします。

直し方：内容を読まず、名前で入口を封鎖する

ここで大事なのが、対処の方向性です。「今後は気をつけます」で終わらせるのは、いちばんやってはいけないパターンでした。人の注意力は必ず切れます。だから私たちは、秘密らしき名前のファイルを保存しようとした瞬間に、機械が自動で止める門を入口に置きました。仕組みとしては、保存の直前に走る検査（pre-commitフックと呼ばれる仕掛け）が、ファイル名のパターンだけを見て「これは危ない名前だ」と判断し、記録そのものを拒否します。中身は読みません。名前だけで門前払いする。

中身を読まないのがポイントです。中身を解析して秘密かどうか判定しようとすると、判定漏れが起きるうえに、そのために秘密を舐めるように読むこと自体がリスクになります。それよりも、拡張子や名前の特徴という「入口の見た目」だけで機械的にはじくほうが、速くて確実で安全です。これは、危険物の中身をいちいち開けて確認するのではなく、持ち込み禁止リストに載った形状のものは入口で全部止める、という空港の保安検査場のような役割だと考えると分かりやすいと思います。同じ発想で、会話ログやデータベースがWebから直接読めてしまう別の穴も見つかったので、そちらはサーバー設定で外部からのアクセスを拒否する形にして塞ぎました。1か所を直すのではなく、「秘密は入口で止める」という原則を、複数の入口すべてに適用するのが再発防止の肝です。

この「入口で止める・出口で止める」という二重の門は、フックと呼ばれる仕掛けで実現しています。仕組みの作り方そのものはフックの実装ガイド記事で詳しく扱っていますが、大事なのは技術ではなく発想です。うっかりミスを人の注意で防ぐのをあきらめ、機械が自動で止める形に置き換える。秘密情報の扱いを組織としてどう設計するかは、見えないところで使われるAIのリスク解説ともつながる話です。

事故で学ぶ②：AIが自分の作文を自分で採点していた

2つ目の事故は、品質チェックにまつわるものです。ある時期まで、記事を書いたAIが、そのまま「ついでに」自分の記事の事実確認と採点もやっていました。効率的に思えますよね。ところが、これが甘かった。自分の書いた文章を自分で採点すると、人間と同じで、どうしても身びいきが働きます。ある記事では、その甘い自己採点をすり抜けた誤りが、別のAIに任せてやり直したところ21か所も見つかりました。1か所や2か所ではありません。採点者と作者が同じだと、チェックは機能しないという当たり前の事実を、数字で突きつけられました。

もっと怖い事故もありました。すでにサービス終了が発表されていた製品を、記事のなかで「これから本格展開する最新サービス」であるかのように紹介してしまったのです。書いたAIは、学習した時点の情報を素直に信じていました。事実として過去のある時点では正しくても、公開する今の時点では間違っている。この「正しさの賞味期限切れ」を、自分では見抜けなかったわけです。

直し方：作る人と採点する人を、必ず別のAIにする

ここから私たちは、鉄則を1つ立てました。作る人と採点する人を分ける。記事を書くAIと、事実確認するAIと、9項目で自己採点するAIを、それぞれ別のサブエージェントとして走らせます。書いた本人には採点させない。さらに、事実確認の手順には「この記事で触れている製品が、今この瞬間にサービス終了していないか」を必ず調べる工程を組み込みました。過去に正しかったかではなく、今も正しいかを毎回確認する。人間の編集部でも、記者と校閲は別の人がやります。それと同じことを、AIの世界でも仕組みとして固定したわけです。

この「役割ごとに別のAIを立てる」という考え方は、サブエージェントという機能があって初めて現実的になりました。サブエージェントは、それぞれが独立した作業空間と専用の指示を持ち、特定の仕事だけに集中する小さな担当者のような存在です。開発元のAnthropicも、サブエージェントの公式ドキュメントで「制約を効かせ、関心を分離するために使う」という考え方を示しています。私たちの運用では、この分離を品質保証の中心に据えました。実際の立て方や指示の書き方はサブエージェント実践ガイドにまとめています。言い換えれば、AIを1体の万能選手として使うのをやめ、役割の違う専門家チームとして編成し直した、ということです。

事故で学ぶ③：AIを並べたら全員が同じ言い回しに収束した

3つ目は、量産にまつわる落とし穴です。記事やX投稿をまとめて作ろうと、複数のサブエージェントを同時に走らせたことがありました。速く大量に作れる——はずでした。ところが出てきた原稿を並べてみると、全員が同じような言い回し、同じ構成、同じ結びに寄っていたのです。語尾の紋切り型や、どこかで読んだような当たり障りのない結びが、どの原稿にも判で押したように並ぶ。まるで金太郎飴のように、どこを切っても同じ断面が出てくる状態でした。

これは偶然ではなく、構造的な現象です。同じ土台のAIに、似た指示で、似たテーマを渡せば、出力が中央値に集まっていくのは自然なこと。放っておくと、量産すればするほど没個性になる。読者にとっては退屈で、検索エンジンにとっては重複コンテンツに見えかねない、二重に困った事態です。

直し方：禁止フレーズと角度割当を、設計書で強制する

対処は2段構えにしました。1つは禁止フレーズのリストです。AIが寄っていきやすい定型句をあらかじめ列挙し、それらが本文に出てきたら検査で弾く。もう1つは角度割当です。量産する各原稿に「この原稿はこの数字・この切り口で書く」という固有の役割を、作り始める前に設計書で割り振っておく。全員に同じお題を渡すのではなく、1体ずつに違う担当を配ることで、収束を構造的に防ぎます。

似た問題は、過去の投稿との重複でも起きました。新しく作った原稿群が、以前出した投稿と同じ統計データを使ってしまい、内容が7割方かぶって検査に引っかかったのです。これも「うっかり」で片づけず、新しい原稿を、過去の投稿全体と自動で照らし合わせて、似すぎていたら公開手前で止める仕組みにしました。人が記憶で重複を避けるのには限界があります。何百本もの過去投稿を人間が覚えていられるはずもないので、そこは機械の記憶に任せる。この「量産は放置すると必ず均質化する」という教訓は、並行して何かを作らせるすべての場面に効く、汎用的な学びでした。

事故で学ぶ④：画像が本番で真っ白になった

4つ目は、目に見える形で表に出た事故です。ある記事を公開したところ、SNSでシェアしたときに表示されるサムネイル画像が、真っ白になっていました。原因は、画像ファイルをサーバーへ転送する途中で通信が切れ、本来より小さい壊れたファイルが本番に届いていたこと。ファイルは「ある」のに「中身が欠けている」という、いちばん気づきにくい壊れ方です。存在チェックだけでは合格してしまい、実際に開くと崩れている。

加えて、画像を生成する仕組み自体にも、環境固有の厄介な癖がありました。手元のパソコン環境には、処理を時間で打ち切るための一般的な道具が入っておらず、それを前提に組んだ処理が全部失敗する。さらに、画像を作るAIは「絵は書き出したのに、その後の後片付けだけが終わらずに固まる」という中途半端な止まり方をしました。ちょうど、料理は完成しているのにコンロの火だけ消し忘れてキッチンに立ち尽くしているような状態です。

直し方：1つの穴を塞がず、5つの層で守る

ここで私たちが選んだのは、「起きた1つの不具合をピンポイントで直す」ことではありませんでした。それをやると、次の未知のパターンでまた別の真っ白画像が出ます。いわゆるモグラ叩きです。代わりに、画像がきちんと表示されるまでの過程を5つの層で多重に守る形に作り替えました。壊れを検出する層、中身が空でないか確かめる層、縦横比や解像度を照合する層、本番と手元のファイルサイズを突き合わせて必要なら送り直す層、そして最終的に本番のURLを叩いて本当に表示されるか確認する層。どれか1つがすり抜けても、次の層が受け止める。

固まる画像生成のほうも、「絵のファイルが安定したサイズで書き出されたら、後片付けを待たずに完了とみなす」という自前の見張り役をAIに組ませて回避しました。これも1つの正攻法にこだわらず、実態に合わせて判定基準そのものを変えた例です。1例だけを潰すのではなく、同じ種類の事故が二度と起きない層構造を作る——このモグラ叩き禁止の姿勢が、長く回る運用と、動くだけの自動化との分かれ目になります。

貫いている5つの設計思想｜お願いでなく仕組みで止める

ここまでの4つの事故は、バラバラに見えて、実は同じ思想から後始末されています。私たちが運用全体を通して守っている5つの設計思想を、ここで整理します。どれも賢い理論ではなく、痛い失敗から逆算して生き残った原則です。

1つ目は、お願いでなく仕組み化。「今後は気をつけます」で終わる対策は、必ず破られます。人の注意力は消耗品だからです。だから注意で守るのをやめ、機械が自動で止める形に必ず落とし込む。品質ゲートも、入口と出口の門も、この思想の産物です。2つ目は、ガードレールはコード側に置き、入力の検出でなく出力を検証する。「悪いものが入ってこないよう見張る」のではなく、「出ていくものが基準を満たしているかを出口で機械が確かめる」。出口検証のほうが、抜け漏れが圧倒的に少ないのです。

3つ目は、モグラ叩き禁止。起きた1例だけを潰すのは、その場しのぎにしかなりません。同じ種類の事故が二度と起きない多層防御を組むか、根本解決が難しいなら「これは軽減しかできていない」と正直に認めて別の道を探す。4つ目は、作る人と採点する人を分ける。書いたAIに採点させない。事実確認も自己採点もレビューも、別のAIに担当させる。5つ目は、追跡した瞬間それは本番公開への片道切符だと心得て、実状態を正とする。秘密は入口で止め、公開されたかどうかは思い込みでなく、実際のURLや応答を叩いて事実で確認する。

これらは特別な理論ではありません。開発元のAnthropicが公開しているClaude Codeのベストプラクティスでも、検査や自動チェックを工程に組み込む考え方が推奨されています。私たちがやったのは、その考え方を「自分たちの事故」で裏打ちし、逃げ場のない形に固定しただけです。ちなみにClaude Codeそのものが何かは公式のOverviewが簡潔で、コードを読み、書き、コマンドを実行し、開発の道具とつながるAIの相棒だと説明されています。

なぜ「AIで回す運用録」が権威性になるのか

ここまで、格好悪い失敗ばかりを並べてきました。なぜわざわざ手の内と事故を公開するのか。理由ははっきりしています。他社が絶対に真似できないのは、成功談ではなく、自分たちが実際に踏んだ地雷とその後始末だからです。きれいな一般論はいくらでもコピーできますが、「秘密メモを2週間流出させて、こう塞いだ」という一次体験は、その経験を持つ者にしか書けません。

これは検索エンジンの評価軸とも一致しています。Googleは、有用で信頼できるコンテンツの指針のなかで、実体験や専門性に裏打ちされた、人の役に立つ情報を優先すると明言しています。制作手段がAIか人間かは問わない、とも。実際、AI生成コンテンツに関するGoogleの見解でも、評価するのは作り方ではなく品質と有用性だと述べられています。だからこそ私たちは、AIで書いている事実を隠しません。隠すのがリスクで、正直に開示するほうがむしろ信頼につながる。これは、いわば身元を明かして話すことそのものが信用の担保になる、という構図です。

法律や規約の面も、正直さが守りになります。自社ドメインの自社名義メディアで、広告主である私たち自身が一人称で発信している以上、これは誰が見ても明白なオウンドメディアであり、ステルスマーケティングにはあたりません。ステマ規制が問題にするのは「広告なのに広告と分からない見せ方」です。AIが中立の第三者を装ってレビューを書く、といった見せ方だけは避け、あくまで自社の立場だと分かる第一者性を保っています。Xでの配信についても、自社オリジナルの投稿を予約して出しているだけで、同じ文面を大量生産したり複数アカウントに拡散したりはしていません。ツールの利用規約に照らしても、1つの契約を無理に共用したり、複数プランをまたいで運用したりと読まれるような使い方はしない——この線を最初から引いています。AI導入がつまずく典型パターンの記事で挙げた失敗の多くも、突き詰めれば「正直さと仕組みの欠如」に行き着きます。

まとめ｜「作る」から「仕組みで止める」へ

AIで業務を回すというと、多くの人は「AIに何を作らせるか」を考えます。でも、約5ヶ月・約200本を積み上げて分かったのは、本当に効くのは逆の問いだということです。「AIが作った悪いものを、どこで機械が止めるか」。この問いに答え続けた結果が、入口と出口の二重の門であり、作る人と採点する人の分離であり、モグラ叩きをやめた多層防御でした。

賢いAIは、あなたの会社でも素晴らしいものを作ってくれます。同時に、止める仕組みがなければ、素晴らしい速度で事故も起こします。だからこそ、良い出力を期待する前に、悪い出力を機械が自動で止める門を先に置く。この順番だけで、事故の大半は起きる前に消えます。私たちが公開した5つの設計思想は、どれも特別な才能を必要としません。必要なのは、うっかりを人の注意で防ぐのをあきらめ、仕組みに翻訳する覚悟だけです。AIを「賢い外注先」ではなく「仕組みで囲う対象」として扱う——この視点の切り替えが、AIで業務を回す第一歩になります。

よくある質問

AIにブログやSNSの運用を任せると、記事の品質はどう担保するのですか？

品質を「お願い」ではなく「機械が止める仕組み」で担保します。文字数・見出し構成・内部リンクの実在・事実確認ファイルの有無・言い回しの重複まで、公開前に検査スクリプトが自動チェックし、1つでも基準を割ると公開そのものが止まります。さらに、記事を書いたAIとは別のAIが事実確認と自己採点を担当する二段構えです。作る人と採点する人を分けるのが肝で、同じAIに書かせて同じAIに採点させると、必ず甘い点がつくからです。人間は最後に自分の目で1回見て、ゴーサインを出す役割に絞っています。

「AIが書いている」と公開して、SEOやステマ規制の面で問題になりませんか？

自社ドメインの自社名義メディアで、広告主である自社が一人称で書いている限り、ステマ規制の観点では問題になりにくい構図です。ステマ規制が問題にするのは「広告なのに広告と分からない見せ方」であって、自社が自社の名前で発信していることは明確な第一者表示だからです。SEOについても、Googleは制作手段がAIか人間かではなく、読者にとって有用で信頼できるかを評価すると明言しています。むしろAIで作っている事実を隠さず正直に書くことは、透明性としてプラスに働きます。

エンジニアでなくても、AIで業務を自動化できますか？

できます。私たち自身、コードを自分で書くのではなく、AIに指示して作らせ、壊れたらAIに直させるという進め方で運用を組み上げてきました。大切なのは自分でプログラムを書く力ではなく、「どこを人間が握り、どこを機械に止めさせるか」という線引きを設計する力です。最初から完璧を狙わず、毎日30分以上かけている作業を1つ選び、そこをAIに半自動化させるところから始めるのが、失敗の少ない順序です。

AIで業務を回すとき、最初に作るべき仕組みは何ですか？

「壊れても気づける・壊れても外に出ない」ための門を最初に作ることです。秘密らしき名前のファイルを保存しようとした時点で止める入口の門と、品質基準を割った成果物が公開へ進むのを止める出口の門を、いちばん最初に固めるのがおすすめです。AIは賢いですが、指示のすき間から予想外のことをします。良い出力を期待する前に、悪い出力を機械が自動で止める仕組みを先に置く。この順番を守るだけで、事故の大半は起きる前に潰せます。

参照元・出典

• Claude Code Overview（Anthropic 公式ドキュメント） — コードを読み書きし、コマンドを実行して開発ツールとつながるAIコーディングツールの概要。
• Claude Code サブエージェント（Anthropic 公式ドキュメント） — 役割ごとに独立した作業空間と権限を持たせ、関心を分離してタスクを委譲する考え方。
• Claude Code ベストプラクティス（Anthropic 公式） — 検査や自動チェックを工程に組み込み、繰り返し作業を仕組み化する運用指針。
• Creating Helpful, Reliable, People-First Content（Google 検索セントラル） — 実体験や専門性に裏打ちされた、人の役に立つ情報を評価するという指針。
• Google Search’s guidance about AI-generated content（Google 検索セントラル） — 制作手段ではなく品質と有用性で評価するという公式見解。