資料、全部読めていますか？社内AIの読み込みを点検する21項目

AI実務ノート｜仕事の返信・共有文例

2026年9月14日 09:00

社内AI 実践ノート 02｜全文無料

AIの回答が自然でも、資料が全部読めているとは限りません。この記事では、資料の取りこぼしと同期処理の失敗を発見した記録から、入力・処理・出力・運用の21項目を点検します。

記載の件数・費用は当時の個別環境の実績です。コードは設計を説明する抜粋で、補助関数や保存先などは環境に合わせた実装が必要です。キャッシュは完了印だけでなく、各分割の存在・順序・内容も検証してください。

前回、社内AIを外注せずに自分で作った話を書きました。1ヶ月、月2,000円で動いています。

今回はその続きで、動いていたはずのものが、静かに壊れていた話です。

1ヶ月でいちばん時間を使ったのは、機能を作ることではありませんでした。「壊れていることに気づく」ことでした。

そして、見つけた壊れ方は、ほぼ全部が同じ構造をしていました。

1ヶ月で見つけた「黙って失敗していた箇所」は10件

10件、全部並べます。右側は「エラーが出たか」です。

1ヶ月間、資料の2割が読み込まれていなかった → 出ない
キャッシュに入りきらず、毎回原本を読み直していた → 出ない
安全のための禁止ルール20件が、0件で動いていた → 出ない
AIが存在しない社内制度を創作し、堂々と提示した → 出ない
69回の回答に対して、フィードバックが0件だった → 出ない
データの一部だけ読んで「成功した」と判定していた → 出ない
正しい指示が長い文書に埋もれて、効いていなかった → 出ない
記録を自動保存する仕組みが、11回連続で失敗していた → 出ない
資料が1文字も無い領域を、AIが詳細に語っていた → 出ない
別の自動処理が、2ヶ月間、毎日失敗し続けていた → 出ない

10件すべて、エラーは1件も出ていません。

システムは動いていました。画面はきれいに表示され、AIはよく喋り、それらしい答えを返していました。動いているように見えることが、いちばん危険でした。

今回は、この中から 1番と10番を書きます。この2つは、原因も現れ方もまったく違うのに、構造が同じでした。

ケース1：事例集が、1件も読み込まれていなかった

このAIは、社内資料を全文読み込んで答える作りにしました。検索の仕組みは作らず、関連する資料を丸ごとAIに渡す方式です（前回書いた話です）。

資料は共有ドライブのフォルダに置きました。フォルダ名の先頭の番号で「この相談ではこのフォルダを読む」と切り替えます。

資料/
　├ 00_共通/      ← 全部の相談で読む
　├ 10_手続き/
　├ 20_評価基準/
　├ 30_事例/
　└ 90_人格/

シンプルです。フォルダに文書を放り込めば、次からAIが読む。非エンジニアが運用できる形にしたかったので、意図的にこうしました。

1ヶ月後、読み込み文字数を数える関数を書きました。そこで初めて気づきました。

事例集が、1件も読み込まれていませんでした。

似た相談が来たときに参照するための事例が20件ありました。AIの回答の具体性を支える中核データです。 「同じような相談が過去にあって、こう整理された」と言えるかどうかは、回答の質に直結します。

読み込めていた資料は、全体の8割でした。 残りの2割が、1ヶ月間まったく使われていませんでした。

気づけなかった原因は2つ。どちらもエラーを出さない

1つめ。フォルダ名が番号で始まっていなかった。

コードはこう書いてありました。

// 先頭の番号だけで判定する。後ろに説明書きを足しても壊れないように
if (folder.getName().indexOf(prefix) === 0) found.push(folder);

「00_共通（全部の相談で読む）」のように、番号のあとに説明を足しても動くようにした配慮です。この判定自体は、正しく動いていました。

ただし、番号で始まらないフォルダは、判定にすら入りません。

そして事例集は「表（マスタ・事例）」という名前のフォルダに入っていました。番号がありません。走査対象から、静かに外れていました。

自分で作ったフォルダです。 自分で番号を付け忘れて、自分で気づけない仕組みにしていました。

2つめ。ファイル形式が読めないものだった。

事例集は表計算ファイルでした。コードはこうです。

if      (mt === 'application/vnd.google-apps.document')     text = docToText_(id);
else if (mt === 'application/vnd.google-apps.spreadsheet')  text = sheetToText_(id);
else if (mt.indexOf('text/') === 0) text = blob.getDataAsString('UTF-8');
else continue;   // ← PDF / xlsx / docx はここで黙って飛ぶ

最後の `continue` です。読めない形式は、何も言わずに飛ばしていました。

書いたときの気持ちは、はっきり覚えています。「PDFが混ざっていても落ちないように」 です。運用するのは自分だけではないので、変なファイルが置かれても止まらないようにしたかった。

落ちないようにした結果、入れたつもりのものが入っていないことに気づけない仕組みになっていました。

気づいたきっかけは、文字数を数える関数だった

きっかけは、機能の追加ではありません。「読み込めた文字数を返す関数」を書いたことです。

// 相談の種類ごとに、資料が何文字読めているかを返す。
// 以前は共通フォルダだけを見て「準備OK」と判定していたが、
// それだと評価基準や事例が空でも正常に見えてしまう。
function canonStatus_() { ... }

数字が出た瞬間に分かりました。事例を含む相談の文字数が、含まない相談とまったく同じでした。

見た瞬間に、背筋が寒くなりました。1ヶ月ぶんの「回答がなんとなく浅いな」という感覚に、全部説明がついたからです。

わたしはその1ヶ月、プロンプトを何度も書き直していました。「もっと具体的に答えて」「事例を使って」と指示を足していました。指示を足す先に、事例が存在していませんでした。

ケース2：別の自動処理が、64日間、毎日失敗していた

こちらは、AI本体ではなくデータを取り込む側の話です。

別のシステムから毎日データを取ってきて、集計用のデータベースに入れる処理を作りました。毎日3時に自動で走ります。作った日にちゃんと動いて、記録も残りました。

2ヶ月後、そのデータを使おうとして気づきました。

最新のデータが、64日前で止まっていました。

ここが不気味なところです。処理は死んでいませんでした。

タスクは「実行可能」の状態で生きている
毎日3時に、ちゃんと起動している
そして毎日、きちんと落ちている
次回の実行予定も、正しく入っている

止まっているのではなく、毎日失敗していました。 そして64日間、誰も気づきませんでした。

ログは書いていました。書けていませんでした

わたしは失敗に備えて、処理の失敗をログファイルに書くようにしていました。そのファイルを開いたら、こうなっていました。

2026-06-29 17:01  同期完了: 15件を反映。総行数=2901
2026-07-24 09:33  エラー: null 値の式ではメソッドを呼び出せません。

7月24日に1回エラーを書いて、それ以降、何も書かれていません。

つまり、ログを書く行に到達する前に落ちていました。 エラー処理より手前で死ぬと、エラー処理は動きません。当たり前の話ですが、「ログを見れば分かる」と思っていた自分の想定が、そこで崩れました。

原因はどうでもいいことでした。認証情報を暗号化して保存していて、その復号が空を返していただけです（同じユーザー・同じ端末でしか復号できない方式だったため）。

問題は原因ではありません。失敗しても、失敗したことがどこにも出なかったことです。

2つに共通していた構造

ケース1は「読めないものを黙って飛ばす」。ケース2は「失敗を誰も読まない場所に書く」。

原因は全然違います。でも、同じことをしています。

どちらも、親切心で作られています。

「変なファイルが混ざっても止まらないように」
「処理が落ちてもシステム全体が止まらないように」

そして、どちらも沈黙とセットで実装されています。

わたしはこの1ヶ月で、同じことを何度もやりました。

例外を握りつぶして、ログに書いた。そのログを誰も読まなかった
「無い場合は空文字を返す」にした。空で動き続けた
「一部でも読めたら成功」にした。一部だけ読んで成功と判定した

親切心は、たいてい沈黙とセットで実装されます。 これが、この記事でいちばん言いたいことです。

LLMを使うと、発見がさらに遅れる

普通のシステムなら、データが無ければ画面が空になります。空欄を見れば異常だと分かる。

LLMは、資料が2割足りなくても、残り8割で自然な文章を作ります。

しかも「自信がなさそうに」ではなく、堂々と、それらしく答えます。だから出力を見ても分かりません。

出力が自然であることは、入力が正しいことの証拠になりません。

ここが、AIを使った仕組みの厄介さです。壊れているかどうかを、成果物から判定できない。 だから、成果物ではなく入力の量を数える必要がありました。

いま同じものを作るなら、機能より先に「数える関数」を書く

機能を1つ作る前に、「入っている量を数える関数」を書きます。

理由は単純で、数えないと分からないからです。そして数える関数は、機能が動き出したあとに書こうとすると、永遠に後回しになります。 動いているものを疑う理由が無くなるからです。

そして、記録の向きを変えました。

「読めた」を記録するのではなく、「読もうとしたが読めなかった」を記録する。

この向きが決定的でした。読めたものだけを記録すると、記録に無いものが「まだ読んでいない」なのか「読めなかった」なのか、区別できません。

実装1：読めなかったものを、必ず1行残す

さきほどの `continue` を、こう書き換えました。

var SKIP = [];   // 読めなかったものの記録

files.forEach(function (f) {
  var mt = f.getMimeType(), id = f.getId(), name = f.getName(), text = null;

  if      (mt === 'application/vnd.google-apps.document')     text = docToText_(id);
  else if (mt === 'application/vnd.google-apps.spreadsheet')  text = sheetToText_(id);
  else if (mt.indexOf('text/') === 0) text = f.getBlob().getDataAsString('UTF-8');
  else {
    // ★ ここが本題。飛ばすが、飛ばしたことを必ず残す
    SKIP.push({ name: name, mime: mt, reason: 'unsupported_mime' });
    return;
  }

  if (!text || !text.trim()) {
    // ★ 形式は読めたが中身が空、も別の理由として残す
    SKIP.push({ name: name, mime: mt, reason: 'empty_text' });
    return;
  }

  rows.push({ name: name, chars: text.length, text: text, status: 'ok' });
});

肝は3つです。

1つめ。`reason` を分ける。 「形式が非対応」と「中身が空」は、原因も対処も違います。前者はファイルを変換すればよく、後者は資料そのものを疑う必要があります。同じ「読めなかった」に混ぜると、原因を追う手間が倍になります。

2つめ。SKIP も一緒に保存する。 画面のログだけに出すと、実行した瞬間しか見られません。わたしは読み込み結果を保存するテーブルに、成功も失敗も同じ形で入れました。

name          | chars | status  | skip_reason
資料A          | 12483 | ok      | (null)
資料B          |     0 | skipped | unsupported_mime
資料C          |     0 | skipped | empty_text

成功と失敗を別の場所に書かないこと。 別の場所に書くと、失敗のほうを見に行かなくなります。同じ表に並べると、眺めるだけで異常が見えます。

3つめ。件数を突き合わせる。 これが決定的でした。

// フォルダ内のファイル数と、記録した行数が一致するか
if (rows.length + SKIP.length !== fileCount) {
  throw new Error('取りこぼしがあります: 対象' + fileCount
                + ' / 成功' + rows.length + ' / 失敗' + SKIP.length);
}

「成功」と「失敗」を足して「対象」になるか。 ここが合わないなら、どちらにも記録されずに消えたファイルがあります。

わたしの事故は、まさにこれでした。フォルダ自体が走査対象から外れていたので、対象の数え方そのものが間違っていました。

だから、対象の数はフォルダを走査したコードとは別の経路で数えます。同じコードで数えると、同じバグで両方間違います。

実装2：完了マーカーを、必ず最後に書く

読み込みが途中で止まったとき、それを「途中で止まった」と判定できる必要があります。

やった方法は単純です。「完了しました」という印を、いちばん最後に書く。

function refreshCanon() {
  var buildId = Utilities.getUuid();

  scanAll_(buildId);        // ここで大量の行を書く
  // ...途中で実行時間の上限に当たると、ここで止まる

  // ★ 全部終わってから、最後にこの1行を書く
  writeRow_({ build_id: buildId, status: 'build_complete', built_at: new Date() });
}

そして読む側は、`build_complete` がある取り込みだけを使います。

-- 完了マーカーがあるビルドの、最新だけを使う
SELECT build_id FROM canon
WHERE build_id IN (SELECT build_id FROM canon WHERE status = 'build_complete')
ORDER BY built_at DESC LIMIT 1

これで、完了済みのビルドだけを選べるようになります。

この考え方は、分割して保存するときにも使えます。 大きい資料をキャッシュに分割して入れるとき、「分割数」を最後に書きます。 読む側は、分割数が書かれていなければキャッシュを無効として扱います。3つ書いたところで止まったら、全体が無効になって、素直に原本から読み直します。

途中で死んだものを「使えない」と判定できる形にしておく。 これができていないと、部分的なデータで平然と動きます。

実装3：原本と、取り込み済みを突き合わせる

資料を更新したのに、取り込み直すのを忘れる。これも黙って失敗します。古い資料で、自然な回答が返ってくるからです。

対策はこうしました。

function canonStatus() {
  var drive  = listSourceFiles_();     // 原本の更新日時
  var loaded = loadedFiles_();         // 取り込み済みの更新日時

  var stale = [], missing = [], extra = [];

  drive.forEach(function (d) {
    var l = loaded[d.id];
    if (!l) missing.push(d.name);                            // 原本にあるが未取り込み
    else if (d.modified > l.modified) stale.push(d.name);    // 原本のほうが新しい
  });
  Object.keys(loaded).forEach(function (id) {
    if (!drive.some(function (d) { return d.id === id; })) extra.push(loaded[id].name);
  });                                                        // 取り込みにあるが原本が消えた

  return { stale: stale, missing: missing, extra: extra };
}

3方向を見ます。 「古い」だけでなく「未取り込み」と「原本が消えた」も。

3つめが意外と効きます。 資料を差し替えたときに、古い資料が取り込み側に残り続けるからです。

わたしは実際にこれで、差し替えたはずの古い資料が残っていて、新旧2つが同時に読み込まれている状態を見つけました。AIは両方を根拠に答えていました。矛盾した回答が出た理由が、これでした。

実装4：エラーを検知するのではなく、成功の鮮度を出す

ケース2（64日間の失敗）から学んだことです。これはコードの話ではなく、置き場所の話です。

わたしは失敗をログファイルに書いていました。2ヶ月、一度も開きませんでした。

だから、こう変えました。

失敗は、必ず「毎日見る場所」に出す。

毎朝見るチャットに1行流す
毎日開くダッシュボードに出す
そして——「最後に成功した日時」を出すのが、いちばん効きます

理由があります。「エラーが出たら通知」だと、通知の仕組みが壊れたときに無音になります。

わたしのケースがまさにそれでした。ログを書く行の手前で落ちていたので、エラー処理そのものが動いていませんでした。

「最後に成功したのはいつか」を常に表示していれば、通知が壊れても、日付が古いことで気づけます。

最終成功：2026-06-29 17:01   ← 64日前。これが表示されていれば即座に分かった

エラーを検知するのではなく、成功の鮮度を表示する。 向きを逆にするのが肝です。

そしてもう1つ。「実行された」と「成功した」を別に記録してください。 タスクは毎日実行されていました。実行ログだけ見ていたら「毎日動いている」と読めます。

実装5：「AIが資料不足を申告した回答」を自動で集める

これは毛色が違いますが、いちばん費用対効果が高かった仕組みです。

AIには「資料に無いことは、無いと言う」と指示しています。だったら、その申告を集めれば、資料の穴のリストになります。

回答の本文を検索するだけです。

SELECT
  DATE(ts) AS d,
  question,
  answer
FROM chat_log
WHERE kind = 'answer'
  AND REGEXP_CONTAINS(answer, r'知識ベースに|入っていない|載っていない|資料が')
ORDER BY ts DESC

これで、社員が会社に聞きたいのに答えが用意されていない項目が並びます。1ヶ月で14件出てきました。

そして重要なのは、最新の質問から見られることです。このSQLは日時の新しい順です。頻度の順位を知るには、質問を分類して件数を別途集計します。

アンケートでは絶対に出てこない解像度でした。 「制度が分かりにくい」ではなく、実際の質問文そのものが並びます。

社内AIを作る人には、これを最初に作ることを勧めます。AIの品質を上げる道具としてではなく、会社の課題を見つける道具として効きます。

そのまま使えるチェックリスト

作ったものが「黙って失敗していないか」を確かめる項目です。上から順に、費用対効果の高い順に並べています。

入力（資料の読み込み）

資料が「何文字」読めているかを返す関数があるか
その数字を、種類別・ファイル別に出せるか
読めなかったファイルも1行記録しているか
記録の理由が「非対応形式」と「中身が空」で分かれているか
成功と失敗を足したら、対象数と一致するか
対象数を、走査コードとは別の経路で数えているか
完了マーカーを最後に書いているか
読む側が、完了マーカーの無いデータを無効にしているか
原本と取り込み済みを、3方向（古い・未取り込み・原本消滅）で突き合わせているか

処理（自動実行）

「最後に成功した日時」を表示しているか
「実行された」と「成功した」を別に記録しているか
失敗が、毎日見る場所に出るか
`catch` した先に、人が読む経路があるか
エラー処理より手前で落ちた場合を想定しているか
途中で時間切れになったとき、それが判別できるか

出力（AIの回答）

「資料に無い」と答えた回答を、自動で集めているか
回答に、どのバージョンの資料を使ったかが記録されているか
同じ質問を再現できるだけの情報がログにあるか

運用

資料を差し替えたあと、反映されたことを確認する手順があるか
その確認を、資料を差し替える人自身ができるか
設定を変えたとき、古い説明が残っていないか探す手順があるか

最後の項目が、実はいちばん刺されました。

設計を変えたのに、古い説明が残っている。 これをわたしは1ヶ月で4回やりました。エラーメッセージ、画面の表示、テストのラベル、そしてAIへの指示文。

直したつもりの場所が、別のところに複製されていました。 そして残った古い説明のせいで、AIが事実と違うことを言いました。

明日からやること（30分）

10分：いま動いているものの「入っている量」を数える

AIに読ませている資料でも、毎日動いている自動処理でもいいです。成果物ではなく、入力の量を数えてください。

10分：その数字が想定と合っているか確かめる

合っていなければ、そこに1ヶ月ぶんの説明がついています。わたしはここで背筋が寒くなりました。

10分：「最後に成功した日時」を、毎日見る場所に出す

まずは成功した日時を表示し、必要なエラー通知も併用します。成功の鮮度だけで、64日間の沈黙は防げました。

社内AI 実践ノート

このシリーズは全文無料です。構築、資料の取り込み、架空回答の判定、評価、会社の見解、造語の順で読めます。

AIへの依頼を、日々の仕事で使うなら

管理職が無料で試せる依頼文で、調査・比較の目的と完成条件を書いて試せます。Excel・7種類の実務別指示文・完成サンプルが必要な方には、AI業務委任・検品キット（980円）を用意しています。