AIに資料を全部渡してよいか｜精度が落ちる理由と、結果の確かめ方

2026年9月15日 11:19

社内の規程やマニュアルをAIに読ませて、質問に答えさせたい。
そう考えたとき、多くの人が最初にやることは同じです。
手元にある資料を、全部入れる。

多いほど正確になるはずだ、という感覚があります。
そうはなりません。
AIを提供している会社の技術資料には、渡す情報が増えるほど、その中の情報を正確に思い出す能力は下がると書かれています。

この記事では、AIに仕事を渡すときにつまずく4つの場面を、公式の技術資料にあたって確かめます。
資料の渡し方、返ってきた表の読み方、まとめて渡したときの並び、PDFの図の扱いです。
4つに共通しているのは、どれもエラーが出ないまま間違いが通ってしまう、という点です。
そのうえで最後に、どこまでを任せるかの決め方を置きます。

この記事は、Anthropicが公開している技術資料をもとに、2026年9月時点の内容にしています。仕様は製品と提供経路によって違います。お使いの製品の公式資料で確認してください。

AIに資料を全部渡すと、なぜ精度が落ちるのか

渡せる情報は「有限の資源」として扱われている

Anthropicが2025年9月29日に公開した技術記事があります。
「Effective context engineering for AI agents」という題で、AIに渡す情報をどう組み立てるかを扱ったものです。

その冒頭で、公式はコンテキストを「決定的に重要だが、有限の資源である」と説明しています。
コンテキストというのは、AIに一度に渡している情報のまとまりのことです。
質問文だけでなく、貼り付けた資料も、前のやりとりも、全部これに含まれます。

有限の資源だ、と説明されています。
多いほどよい、とは書かれていません。

崖ではなく、坂で落ちる

なぜ有限なのか。
同じ記事に説明があります。

公式は、干し草の山から針を探す形の測定によって「コンテキストの劣化」という現象が分かってきたと説明しています。
コンテキストの中の情報量が増えるほど、その中の情報を正確に思い出す能力は下がる、という現象です。
そして、落ち方がゆるやかなモデルもあるが、この性質はすべてのモデルに現れるとしています。

落ち方についても、はっきり書かれています。
公式は、これらの要因は急な崖ではなく「性能の勾配」を作ると説明しています。
長いコンテキストでもモデルは高い能力を保つが、短いときと比べると、情報の取り出しと長い範囲の推論では精度が下がることがある、という書き方です。

ここが実務では厄介です。
崖なら分かります。
入れすぎた瞬間にエラーが出れば、気づけます。

坂なので、気づきません。
10件入れたときも50件入れたときも、それらしい答えが返ってきます。
ただ、正確さが少しずつ落ちています。

古い規程を一緒に入れると、どうなるか

具体的な場面で考えます。

就業規則についてAIに答えさせたいとします。
フォルダには、現行版と、去年の版と、改定案が入っています。

全部入れると、どうなるか。
AIは、どれが現行かを知りません。
日付の入ったファイル名を見て推測することはできますが、確実ではありません。

そして、答えは1つ返ってきます。
「旧版によれば」とは書かれずに、混ざった答えが返ってくることがあります。

これが、資料を全部入れることの本当の危険です。
量が増えて精度が落ちるという話より前に、矛盾する資料を同時に渡している、という問題があります。

人間なら「これは古いやつですね」と言います。
AIは、そう言うように作られていない限り、言いません。

減らせばよい、という話ではない

ここで注意が要ります。
減らせば必ず良くなる、という話ではありません。

同じ記事には、最小限とは短いという意味ではない、という注記があります。
望む動きをさせるために必要な情報は、前もって十分に与える必要がある、という書き方です。

目指すところも書かれています。
公式は、よいコンテキストの設計とは、望む結果が出る見込みを最大にする、密度の高い情報の最小の組み合わせを見つけることだと説明しています。

削るのではなく、選ぶ。
これが設計です。

何を入れるかを決める、という仕事

実務に落とします。
やることは3つです。

1つ目、渡す資料に「現行」の印を付ける。
フォルダから全部入れるのをやめて、現行版だけを入れる場所を1つ作ります。
旧版は別のフォルダに移します。
これはAIのための作業ではなく、人間のためにも要る作業です。

2つ目、入れる資料に日付と適用範囲を書き添える。
「2026年4月1日から適用」「対象は正社員のみ」。
この一行があるかないかで、答えが変わります。

3つ目、答えの根拠を出させて、原文と突き合わせる。
どの資料のどこを見て答えたのかを一緒に出させます。
そして、たまに原文を開いて確かめます。
毎回でなくて構いません。
やっていないと、いつのまにか古い版で回っていることに気づけません。

この3つは、どれもAIの設定ではありません。
資料の側の整理です。

そもそも、その資料を入れてよいかという手前の判断は、別の記事で扱っています。
シャドーAIと、契約するプランによって入力データの扱いが変わる話をまとめています。
https://note.com/yunta_fukurou/n/n0b6b85bdcbb4

表の形で返ってきても、中身が正しいとは限らない

AIに名簿を渡して、分類させました。
返ってきたのは、きれいな表です。
列がそろっていて、空欄もなく、そのまま表計算ソフトに貼れます。

見た瞬間、正しそうに見えます。
形が整っていることと、中身が合っていることは、別のことです。
そして、整った形は、疑う気持ちを弱めます。

形式をそろえる機能は、実際にある

まず、仕組みを確認します。

AIの出力を決まった形式に従わせる機能があります。
「構造化出力」と呼ばれるものです。
日本語の公式ドキュメントに、こう説明されています。

「structured outputs」（構造化出力）は、Claudeの応答が特定のスキーマに従うように制約し、下流の処理のために有効で解析可能な出力を保証します。

スキーマというのは、返ってくる形の設計図のことです。
どの項目があるか、それぞれが文字列なのか数値なのか、どれが必須か。
これを先に決めておきます。

何が保証されるのかも、箇条書きで書かれています。

常に有効： JSON.parse()エラーはもう発生しません

型安全：フィールドの型と必須フィールドが保証されます

信頼性：スキーマ違反による再試行は不要です

これは本物の機能です。
形式は本当にそろいます。

保証されているのは、形式です

ここが、この章でいちばん言いたいところです。

いま引用した3行を、もう一度読んでください。
正しい形式であること。
項目の型が合っていること。
必須項目が埋まっていること。

どれも形の話です。
中に入っている値が事実として正しいかどうかについては、書かれていません。

つまり、「氏名」の列に文字列が入っていることは保証されます。
その文字列が、渡した名簿の氏名と一致しているかどうかは、別の話です。

「金額」の列に数値が入っていることは保証されます。
その数値が、請求書に書いてあった金額かどうかは、別の話です。

機能の説明を読み違えて、「形式が保証されているから中身も大丈夫」と考えると、ここで転びます。

形が崩れる場合も、2つ書かれている

同じドキュメントに、形式が保証されない場合が2つ挙げられています。

1つ目は、AIが安全上の理由で応答を拒否した場合です。

拒否メッセージがスキーマ制約よりも優先されるため、出力がスキーマに一致しない可能性があります

2つ目は、出力の長さの上限に達して、途中で切れた場合です。

出力が不完全でスキーマに一致しない可能性があります

つまり、形式が保証されるのは正常に終わったときであって、常にではありません。
100件渡して95件で切れていた、という事故はここから起きます。
表としては成立しているので、見た目では分かりません。

エラーも出ないまま、選択肢が1文字変わることがある

もう1つ、同じドキュメントにはっきり書かれている注意があります。
分類の選択肢を決め打ちにしたときの話です。

構造化出力は文字列のenumおよびconst値の大文字小文字を保証しません。

そして、そのときどうなるかも書かれています。

応答はエラーも特別なstop_reasonもなく正常に完了します。

公式が挙げている例は、英語の選択肢です。
「Conversation Topic 1」のように選択肢を決めておいても、単語の頭文字の大小が変わった値が返ることがある、という説明で、日本語の選択肢でどうなるかは書かれていません。

ただ、実務として受け取るべきことは、はっきりしています。
決めた選択肢と1文字違う値が、エラーなしで返ってくる場合がある、ということです。
返ってきた値を表計算ソフトの関数でそのまま数えていると、件数が合わなくなります。
そして、合計が合わない理由は画面のどこにも出ません。

選択肢を決めたのなら、返ってきた値が本当にその選択肢の中にあるかを、数える前に確かめる。
これが対処です。

項目の順番も、書いた順とは限らない

同じドキュメントに、もう1つ具体的な注意があります。

構造化出力を使用する場合、オブジェクト内のプロパティはスキーマで定義された順序を維持しますが、1つ重要な注意点があります。必須プロパティが最初に表示され、その後にオプションプロパティが続きます。

設計図に書いた順ではなく、必須の項目が先に来て、そのあとに任意の項目が並びます。
列の並びを決め打ちにして、左から順に貼り付けるような処理をしていると、ここでずれます。

対処も書かれています。

出力内のプロパティの順序がアプリケーションにとって重要な場合は、すべてのプロパティを必須としてマークするか、解析ロジックでこの並べ替えを考慮してください。

受け入れ検査を、3つに分ける

実務としては、確認を3つに分けます。

件数。渡した件数と返ってきた件数が合っているか
項目。必要な列がそろっていて、空欄がないか。列の並びが想定どおりか
値。返ってきた値が、元の資料と一致しているか

このうち、1つ目と2つ目は機械的にできます。
表計算ソフトの関数で足ります。

3つ目だけが、人の目が要ります。
全件は無理なので、何件か抜き取ります。

抜き取るときのコツが1つあります。
先頭から10件ではなく、ばらけさせることです。
先頭は、たいてい合っています。

表で返ってきたときほど、疑う

最後に、感覚の話をします。

文章で返ってきた答えは、みんな読み返します。
長いし、読まないと使えないからです。

表で返ってきた答えは、読み返されません。
列がそろっていて、そのまま貼れるからです。

つまり、いちばん確認されないのが、いちばん確認しやすい形をした出力です。

そして表は、そのあと集計されます。
合計され、平均され、グラフになります。
1件の取り違えが、判断に効く数字に化けます。

100件渡した結果を、順番で戻していないか

問い合わせの記録が100件あります。
これをAIに渡して、内容ごとに分類してもらいました。

返ってきた100件を、元の100件の横に貼り付けます。
1行目は1行目の結果、2行目は2行目の結果。
そう思って貼りました。

その前提が崩れることがあります。
しかも、崩れても表は成立します。

公式資料に、順番は保証しないと書いてある

多数の依頼をまとめて処理する仕組みがあります。
「バッチ処理」と呼ばれるものです。

日本語の公式ドキュメントに、見出しでこう書かれています。

バッチ結果は入力順序と一致しない場合があります

本文も、同じことをはっきり書いています。

バッチ結果は任意の順序で返される可能性があり、バッチ作成時のリクエストの順序と一致しない場合があります。

そして、対処もそのあとに続きます。

結果を対応するリクエストと正しく一致させるには、常にcustom_idフィールドを使用してください。

ベストプラクティスの節でも、もう一度出てきます。

順序が保証されないため、結果とリクエストを簡単に一致させるために意味のあるcustom_id値を使用します。

順序は保証されない、と2か所に書かれています。

なぜ順番がずれるのか

仕組みを考えると、当然の話です。

まとめて渡した依頼は、同時に処理されます。
1件目から順に片づけていくわけではありません。

そして、1件ごとに掛かる時間が違います。
短い記録はすぐ終わり、長い記録は時間が掛かります。

先に終わったものから返ってくれば、順番は入れ替わります。

これは不具合ではありません。
速くするための仕組みが、そういう作りだというだけです。
問題は、受け取る側が順番を前提にしていることです。

番号で突き合わせる

対処は1つです。
順番ではなく、番号で突き合わせます。

渡すときに、1件ずつ番号を付けます。
受付番号でも、行番号でも構いません。
ただし、重複しないものにします。

公式ドキュメントも、この番号の決まりを書いています。

Messagesリクエストを識別するための一意のcustom_id。1〜64文字で、英数字、ハイフン、アンダースコアのみを含む必要があります

返ってくる結果にも、その番号を一緒に返させます。
そして、貼り付けるときは、順番ではなく番号で照合します。
表計算ソフトなら、番号をキーにして結合します。

これだけで、この事故は起きなくなります。

なお、番号の付け方には注意が要ります。
氏名や電話番号を番号の代わりに使うと、同姓同名や同じ番号があったときに崩れます。
突き合わせに使う値は、1件に1つでなければ意味がありません。
連番でよいので、重複しないものを別の列に作ることです。

件数と欠番を、必ず数える

番号で突き合わせると、もう1つ効きます。
欠けに気づけます。

100件渡して、返ってきたのが98件だった。
順番で貼っていたら気づきません。
表は98行になっているだけで、どの2件が抜けたかは分かりません。

番号で突き合わせれば、どの番号が返ってきていないかがすぐ出ます。

確認する項目は2つです。

渡した件数と、返ってきた件数が同じか
渡した番号の一覧と、返ってきた番号の一覧が一致するか

2つ目まで見ると、番号の重複にも気づけます。
同じ番号が2回返ってきていたら、どこかで取り違えが起きています。

表計算ソフトから貼り付けるときも、同じことが起きる

ここまでは、システムからまとめて依頼する場合の話です。
しかし、同じ事故は、もっと身近なところでも起きます。

100行の表をコピーして、チャットの画面に貼り付ける。
返ってきた100行をコピーして、元の表の横に貼る。

このやり方には、番号がありません。
順番だけが頼りです。

そして、返ってくる行数が100行でない場合があります。
長すぎて途中で切れる、まとめられる、空行が入る。
どれも起こります。

貼り付けたあとで行数がずれていれば、そこから下の全部がずれます。
100行目の分類が99行目の名前に付いていても、表としては完成して見えます。

だから、この作業をするときも、番号の列を先頭に付けてから渡してください。
返ってきたら、その番号で並べ直します。
手作業でも、番号を付けるだけで防げます。

PDFの図は、渡し方によって読まれ方が変わる

決算資料のPDFをAIに渡して、要点を聞きました。
文章の部分については、きちんと答えます。
では、そこに載っているグラフの数字は、読まれているでしょうか。

標準では、図も読まれている

まず、できることが書かれています。

提供したPDF内のあらゆるテキスト、画像、チャート、表についてClaudeに質問できます。

仕組みも、手順として書かれています。

システムはドキュメントの各ページを画像に変換します。

各ページからテキストが抽出され、各ページの画像と一緒に提供されます。

Claudeがテキストと画像の両方を分析し、ドキュメントをより深く理解します。

ページを画像にしたうえで、テキストも抜き出して、両方を見る。
これが標準の仕組みです。
つまり、標準では図も読まれています。

ところが、経路によって変わる

同じドキュメントの後半に、条件が変わる経路が1つ書かれています。
Amazon Bedrockという基盤の上で、Converse APIという入口からPDFを渡す場合です。

Amazon Bedrock上のClaude（Opus 4.6以前）の一部であるConverse APIを通じてPDFサポートを使用する場合、2つの異なるドキュメント処理モードがあります

2つのうち、従来のモードについてはこうあります。

PDFからの基本的なテキスト抽出を提供します

PDF内の画像、チャート、視覚的レイアウトを分析できません

もう1つの新しいモードについては、こうあります。

PDFの完全な視覚的分析を提供します

包括的な理解のために各ページをテキストと画像の両方として処理します

そして、どちらになるかは設定で決まります。
従来のモードの説明に、こう書かれています。

引用が有効になっていない場合に自動的に使用されます

同じページの注意書きも、同じことを書いています。

重要： Converse APIでClaudeの完全な視覚的PDF理解機能を利用するには、引用（citations）を有効にする必要があります。引用が有効になっていない場合、APIは基本的なテキスト抽出のみにフォールバックします。

この経路では、設定をしていないと図が読まれません。
しかも、そちらが既定です。

使う量も違います。
3ページのPDFで、テキスト抽出だけなら約1,000トークン、テキストと画像の両方なら約7,000トークンを使うと書かれています。
同じPDFでも、扱われ方がそれだけ違うということです。

図が読まれていない、と気づけるか

問題は、気づけるかどうかです。

図が読まれていないとき、AIは「図は読めませんでした」とは言いません。
文章の部分だけを見て、答えを組み立てます。

そして、その答えは、それらしく読めます。
文章にも数字は書いてあるからです。

グラフにしか書かれていない数字を聞いたときだけ、答えがおかしくなります。
しかし、それが図にしか書かれていないことを、聞く側は知りません。

確かめ方は1つです。
図の中にしかない数字を、1つ選んで聞いてみる。
合っていれば読まれています。

これは、経路が分からないときにも使えます。
社内で導入した道具がどの入口を使っているかは、たいてい利用者には見えません。
1つ聞いてみるほうが早いのです。

表計算ファイルは、そのままでは渡せない

同じドキュメントに、ファイル形式の条件も書かれています。

.txt、.csv、.mdなどのプレーンテキストファイルは、ドキュメントブロックで直接使用できます。

.xlsxや.docxなどのバイナリ形式はドキュメントブロックではサポートされておらず、事前にテキストまたはPDFに変換する必要があります。

これは仕組みの側の条件です。
使っている道具によっては、裏で自動的に変換されている場合もあります。

大事なのは、変換されているなら、そこで何かが落ちている可能性があるということです。
数式は値になり、シートの分かれ方は失われ、書式で表していた意味は消えます。

表計算ファイルを渡して答えが合わないときは、AIの能力ではなく、変換のところを疑ってください。

密度の高いPDFは、ページ数の上限より先に詰まる

もう1つ、同じドキュメントにある注意です。

密度の高いPDF（小さなフォントのページが多い、複雑な表、大量のグラフィックなど）は、ページ制限に達する前に「context window」（コンテキストウィンドウ）を埋め尽くしてしまう可能性があります。

対処も書かれていて、ドキュメントをセクションに分割することが挙げられています。

最初の章で見た有限の資源の話が、ここにもつながります。
ページ数が上限より少ないから大丈夫、とはならないということです。

任せる範囲を、先に決める

ここまでの4つは、渡し方と受け取り方の話でした。
最後に、その土台にある話をします。

「決まった道筋」と「自分で決める」を分ける

Anthropicには、もう1つ技術記事があります。
2024年12月19日付の「Building effective agents」です。
冒頭に、この記事以降に周辺の道具立てが変わっている旨の注記が付いていますが、考え方の整理はいまも使えます。

そこでは、2つの型が区別されています。

公式は、ワークフローを、AIと道具があらかじめ決められた道筋に沿って動かされる仕組みだと説明しています。
一方エージェントは、AIが自分で進め方と道具の使い方を決め、どう仕事を片づけるかを自分で握る仕組みだとしています。

そして、選び方についても書かれています。
公式は、いちばん単純な解き方を見つけ、必要になったときだけ複雑にすることを勧めています。
それは、そもそもエージェント的な仕組みを作らない、という結論になることもある、とまで書かれています。

使い分けの目安もあります。
公式は、はっきり決まった仕事にはワークフローが予測しやすさと一貫性をもたらし、柔軟さとAI自身の判断が大量に必要な場合にはエージェントのほうがよいと説明しています。
多くの用途では、1回の呼び出しを検索と手本で補うだけで十分だ、ともしています。

中小企業の実務でいうと

毎月の請求書を分類する。
決まった様式から項目を抜き出す。
問い合わせを担当ごとに振り分ける。

こういう仕事は、手順が決まっています。
ここに自分で判断する仕組みを入れると、確認する手間が増えるだけです。

逆に、手順が決まっていない仕事は、任せる前にもう1つ考えることがあります。
返ってきた結果を、どうやって確かめるかです。

件数を数える、番号で照合する、抜き取って原文と突き合わせる。
この確かめ方が作れない仕事は、まだ渡す段階にありません。

どこまで任せてよいかを社内のルールにするなら、ひな形があります。
条文と、入力してよいかを社員が判断するための1枚ものをまとめています。

どのモデルに任せるかという選び方は、こちらで扱っています。
モデルと考える深さの違いと、既定のままでよい場面をまとめています。
https://note.com/yunta_fukurou/n/n8db05af9df9a

2026年9月時点の最新状況

この記事が根拠にしている資料の、現在地を並べます。

構造化出力は、試験提供から通常の機能になった

構造化出力は、以前はベータ版として提供されていました。
2026年9月時点の公式ドキュメントには、移行についての案内が出ています。
出力形式を指定する項目の場所が「output_format」から「output_config.format」へ移り、ベータ用のヘッダーは不要になった、という内容です。
移行期間中は古い書き方も引き続き受け付ける、とも書かれています。

自社で作った仕組みが古い書き方のままでも、いますぐ止まるわけではありません。
ただ、いつまでも受け付けるとは書かれていないので、作った人に確認しておく時期です。

PDFの上限は、ページ数だけでは決まらない

PDFの制限は、2026年9月時点で次のように書かれています。

最大リクエストサイズ　32MB（プラットフォームによって異なる）
リクエストあたりの最大ページ数　600。ただしリクエストのコンテキストウィンドウが1Mトークン未満の場合は100
形式　標準PDF（パスワードや暗号化がないもの）

ページ数の上限が2段構えになっている点に注意してください。
600ページという数字だけを覚えていると、100ページで断られたときに理由が分かりません。

経路の話は、モデルの世代で線が引かれている

PDFの章で触れたConverse APIの2つのモードは、公式ドキュメントでは「Amazon Bedrock上のClaude（Opus 4.6以前）」という限定つきで説明されています。
つまり、この話はすべての経路に当てはまるものではなく、特定の基盤の特定の入口についての説明です。

自社がどの経路を使っているかが分からないまま「図は読まれないらしい」と覚えてしまうと、逆に間違えます。
分からないときは、PDFの章の確かめ方を使ってください。

根拠にした技術記事の日付

「Effective context engineering for AI agents」は2025年9月29日公開
「Building effective agents」は2024年12月19日公開。冒頭に、この記事以降に周辺の道具立てが変わっているという注記が付いている

古い記事のほうは、道具の名前や製品の話は変わっています。
この記事で使ったのは、ワークフローとエージェントの区別と、単純な解き方から始めるという考え方の部分だけです。

まとめ

渡す資料は、多いほどよいのではない。公式はコンテキストを有限の資源だと説明している。情報量が増えるほど正確に思い出す力は下がり、落ち方は崖ではなく坂なので気づけない
ただし減らせばよいのでもない。最小限とは短いことではないと明記されている。削るのではなく、現行版だけを選んで渡す
返ってきた表で保証されているのは形式である。値が事実として正しいかどうかは書かれていない。拒否されたときと、長さの上限で切れたときは、形式も保証されない
決めた選択肢と1文字違う値が、エラーも出ないまま返ることがあると書かれている。項目の順番も、必須が先に来る
受け入れの確認は、件数、項目、値の3つに分ける。値だけは人の目が要る。抜き取りは先頭からではなく、ばらけさせる
まとめて処理を依頼したとき、結果の順序は保証されないと公式資料に明記されている。重複しない番号を1件ずつ付けて、番号で突き合わせる。表計算ソフトから貼り付ける手作業でも同じ事故が起きる
PDFは、標準ではページを画像にしたうえでテキストも抜き出し、両方を見る。ただし経路によっては設定をしないとテキスト抽出だけになり、しかもそちらが既定になる場合がある
読まれているかどうかは、図の中にしかない数字を1つ聞けば分かる。表計算ファイルは変換されている前提で疑う
手順が決まっている仕事に、自分で判断する仕組みを入れる必要はない。公式も、いちばん単純な解き方から始めることを勧めている

4つの場面に共通しているのは、どれも「うまくいっているように見える」という点でした。
エラーは出ません。
答えは返ってきます。
表は成立し、文章は読めます。

だから、AIを使う仕事では、確かめる手順を先に決めておくことが本体になります。

皆さんの会社で、AIに任せている仕事のうち、結果を確かめる手順が決まっているものはいくつあるでしょうか。

参考・引用元

コンテキストの設計

Anthropic「Effective context engineering for AI agents」（2025年9月29日公開、2026年9月時点） https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

構造化出力

Anthropic「構造化出力」（Claude Platform Docs 日本語版、2026年9月時点） https://platform.claude.com/docs/ja/build-with-claude/structured-outputs

バッチ処理

Anthropic「バッチ処理」（Claude Platform Docs 日本語版、2026年9月時点） https://platform.claude.com/docs/ja/build-with-claude/batch-processing

PDFの扱い

Anthropic「PDFサポート」（Claude Platform Docs 日本語版、2026年9月時点） https://platform.claude.com/docs/ja/build-with-claude/pdf-support

任せる範囲の決め方

Anthropic「Building effective agents」（2024年12月19日公開、2026年9月時点） https://www.anthropic.com/engineering/building-effective-agents

実務で使う書式について

この連載の内容を、社内でそのまま使える書式にまとめたものを、別のマガジンで公開しています。規程のひな形、対応フロー、チェックシート、報告書式などです。

実務で使う書式・キット
https://note.com/yunta_fukurou/m/mfc25857fab40