事業所名、所在地、電話番号、職員の氏名。同じ情報を、申請書、事業所概要、案内文などへ何度も入力していませんか。変更があるたびに書類を開いて直していると、一つだけ古い情報が残ることがあります。
こうした仕事は、情報をまとめて管理し、必要な書類へ転記する仕組みを作ることで改善できます。この記事では、Codexに作成を依頼し、架空のデータと少数の書類で試す進め方を紹介します。
Codexを使ってみたい人のための初心者ガイド｜基本知識と使い方の実践編です。基本ガイドで扱った「作業フォルダを決める」「目的と変更範囲を伝える」「結果を確認する」を、一つの業務に当てはめます。
1．どんな書類の仕事に使えるか
対象は、複数の書類で同じ情報を使い、繰り返し作成・更新する仕事です。介護事業所を想定しますが、説明に使う事業所名・番号・書類は架空です。行政への提出書類に加え、契約に添付する資料や利用者向け案内も、対象に含めて考えます。
例えば「みどりケア」の電話番号を変更したとします。事業所概要、変更届の作業版、利用者向け案内の3か所に同じ番号があれば、共通台帳の番号を一度変更し、各書類の該当欄を更新する仕組みにできます。変更届の要否や使う様式は、実際の提出先の案内で別途確認します。
ここでいう「一度の変更」は、情報を入力し直す場所を一つにする、という意味です。元データを変更するだけで、PC内の全書類が自動で書き換わるわけではありません。どの項目をどの書類のどこへ入れるかを決め、生成処理を実行し、変更結果を確認する必要があります。
2．共通台帳と、書類ごとの対応表を用意する
最初から大きなデータベースを作る必要はありません。まずはExcelなどで「共通台帳」を用意し、複数の書類が参照する情報の保管場所を一つにします。次に「項目対応表」で転記先を決めます。書類のひな型は、共通情報を入れる場所と、その書類だけで入力する場所を分けて扱います。
| 共通台帳の項目 | 使う書類の例 | 対応付けで確認すること |
|---|---|---|
| 事業所名 | 事業所概要・変更届の作業版・案内文 | 法人名と事業所名を混同しない |
| 電話番号 | 同じ事業所の電話欄 | 代表電話と担当者の連絡先を区別する |
| 所在地 | 事業所概要・案内文 | 法人本店と事業所の所在地を分ける |
| 変更日・適用日 | 変更内容を扱う書類 | 作成日、提出日、適用日を別項目にする |
「住所」と書かれた欄でも、法人本店、事業所、職員の自宅では意味が異なります。項目名が同じという理由だけで共通化せず、誰の情報か、いつの情報か、何に使うかをそろえます。職員が増える場合は、氏名だけで識別せず職員IDなどを使う設計も必要になります。
料金や職員配置に広げるときは、さらに注意が必要です。現行料金と将来の料金、単純な人数と勤務時間から計算する人数は、同じ項目として上書きできません。最初の試作では、こうした計算や制度判断を含めず、電話番号のように意味が明確な項目から始めます。
3．自作する前に、どの方式が合うか選ぶ
Codexで作れる仕組みでも、既存の機能で足りる場合があります。書類数だけで判断せず、様式の変更頻度と、完成後に直す担当者がいるかを確認してください。
| 選択肢 | 候補になる条件 | 確認する負担・制約 |
|---|---|---|
| Excelの参照・Wordの差し込み | 書類が少なく、構造が単純で、共通項目の転記が中心 | ファイル間の参照、書式、変更履歴の管理方法 |
| 既存の業務ソフト | 対象業務・提出先・様式に対応する製品がある | 対応範囲、料金、様式改訂、データの取出し、支援窓口 |
| Codexで個別の仕組みを試作 | 独自書類があり、既存機能では埋まらない転記や検査がある | 原本の解析、開発・確認、実行環境、改訂時の保守担当 |
この記事では3番目を試します。日々の転記は、確認した対応表に従うプログラムで自動化します。共通項目を転記するだけなら、Excelなどを使い、実行時にAIを使わない構成でも対応できます。
AIを取り入れる利点の一つは、法令改正などに伴う文章の変更・追加・削除にも対応しやすくなることです。改正資料と現在の書類を基に、見直す必要がありそうな文章を探し、修正文、新たに加える説明、削除を検討する記述を、理由とともに提案してもらう構成が考えられます。決まった欄への転記に加え、文章の意味を踏まえた見直しを支援する使い方です。
最初は転記の仕組みを作り、次に文章の見直しへ広げます。改訂の際にCodexへ依頼する方式と、完成したシステム内からAIを呼び出す方式では、必要な開発・契約・データの取扱いが異なります。実際の費用と利用条件は選んだ構成に合わせて確認します。
4．試作に必要なものを集める
- 試作用の書類を2〜3種類用意する。最初はWordとExcelを中心にし、同じ電話番号が入る欄を含めます。
- 実データを架空の情報へ置き換える。本文だけでなく、非表示シート、コメント、変更履歴、文書のプロパティにも実情報が残っていないか確認します。
- 仕事専用のフォルダを作る。本番の書類保管場所と分けて、Codexのローカルプロジェクトに指定します。準備操作は初心者ガイドを参照してください。
- 目標と確認担当を決める。今回は「電話番号の変更が3種類の作業版に反映され、原本と対象外の欄が変わらないこと」です。
ローカルフォルダを使っていても、AIへ渡すファイル内容が端末の外へ出ないことを意味しません。実業務の情報を使う前に、組織の利用ルール、契約・データの取扱条件、接続先を確認します。この試作では個人情報や顧客の機密情報を使いません。
例えば、次のように保存場所を分けます。原本は書き換えず、作業版は毎回別の出力先へ保存します。
書類更新の試作/
原本/ 架空データに置き換えた書類
共通台帳/ 事業所情報など
項目対応/ 台帳の項目と転記先の対応表
プログラム/ 転記・検査の処理
出力/ 生成回ごとの作業版
確認記録/ 変更前後の差分と検査結果Word・Excelを開いて確認できる環境も必要です。ファイル処理用の追加ソフトやライブラリが必要と分かった場合は、用途と導入内容を確認してから準備します。PDFは、入力欄付き、文字を含む印刷用、スキャン画像などで対応が違うため、後の段階で原本を確認して判断します。
5．Codexへ段階的に依頼する
最初の依頼で完成形を丸ごと求めず、調査、対応表の確認、試作、検証に分けます。判断が必要な箇所を先に見つけることで、誤った対応付けのまま多くの書類を作ることを防ぎます。
最初の依頼：書類を調べ、共通項目を整理する
用意したフォルダで新しいチャットを始め、対象と制約を伝えます。次の指示のフォルダ名は、自分の保存場所に合わせてください。
プロンプト例（コピーして利用できます）
このプロジェクトの「原本」にある、架空データのWord・Excel書類を調べてください。
目的は、共通情報を一度変更すると、対応する複数の書類の作業版へ反映できる仕組みを試作することです。
まずは読取りだけで調査し、次を提示してください。
・共通にできる項目と、書類固有の項目
・各項目の意味、台帳から転記する場所、対応付けに不明点がある箇所
・電話番号一つを変更して試す最小構成
・必要な実行環境、追加ソフト、制約
原本の変更、ソフトの導入、外部サービスへのファイル送信、提出は行わないでください。
判断できない項目は推測で埋めず、確認事項として示してください。返された対応表では、電話番号の転記先が本当に同じ連絡先かを確かめます。「変更前」と「変更後」の欄がある書類では、両方を新番号にしない設計が必要です。これから作る仕組みの仕様になるため、ここは現場の担当者が確認します。
次の依頼：確認した対応に沿って作る
プロンプト例（コピーして利用できます）
確認済みの項目対応表に沿って、共通台帳と転記プログラムを作ってください。
最初の対象は、同じ事業所の電話番号を使う3種類の書類だけです。
・原本と過去の提出済み書類は変更せず、生成回ごとの出力フォルダへ作業版を保存する
・変更前の値と適用日を残す
・対応付けのない欄や、書類固有の値・数式は変更しない
・必須値や対応先が見つからなければ処理を止め、書類名と理由を示す
・出力書類一覧、変更前後の値、検査結果を残す
・作成途中で失敗した出力は、完了したものと区別する
・実行方法と、失敗時に元へ戻す方法を説明する
架空データで生成・検査まで行い、実施できた確認と未確認の部分を分けて報告してください。
追加ソフトが必要な場合は、導入する前に内容を示してください。外部への提出・送信は行わないでください。作業が終わったら、説明だけでなく実際の出力ファイルを開きます。検査結果に「一致」と表示されても、セルの表示が切れていたり、Wordの改ページが変わっていたりする場合があります。内容の照合と書式の確認は分けて行います。
6．一度の変更が正しく反映されたか確認する
検査に使う期待値は、生成結果を見てから合わせるのではなく、先に担当者が決めます。以下は電話番号を変更する試作の確認例です。
| 試すこと | 期待する結果 | 確認方法 |
|---|---|---|
| 電話番号を旧番号から新番号へ変更 | 3書類の指定欄が新番号になる | 台帳、変更一覧、各出力ファイルを照合 |
| 変更前の番号を残す欄がある | 旧番号が残り、変更後欄だけ新番号になる | 欄の意味と対応表を照合 |
| 同じ番号が対象外の欄にもある | 対象外の欄は変わらない | 全体置換になっていないか差分を確認 |
| 台帳が空欄、または転記先が見つからない | 完了扱いにせず理由を示す | 異常条件を架空データで試す |
| 原本・過去の提出済み書類 | 変更されない | 変更前後のファイル比較 |
| 長い値や文字列の電話番号 | 先頭の0、ハイフン、表示枠が保たれる | Word・Excelで開き、印刷表示も確認 |
問題が見つかったら、「うまくいきません」だけでなく、書類名、欄、期待した値、実際の値をCodexへ伝えます。修正後は失敗した条件と、その修正の影響を受ける書類を再確認します。必要な場合は修正前に戻し、従来の手入力で作成できる原本を残しておきます。
効果は、同じ書類一式について、手作業と試作後の「入力・生成・確認・修正」の合計時間を比べます。初期の設定時間と、日々の運用時間は分けて記録してください。転記ミスや修正漏れの件数も比較材料になります。この記事で効果を実測したものではありません。
7．実務で使う前に決める運用・権限・復旧方法
試作が動いても、そのまま正式な提出書類の作成に使う段階とは限りません。共通台帳を変更する人、項目対応を直す人、書類を承認する人を決め、扱う情報に必要な範囲で閲覧・編集権限を設定します。複数人で使う場合は、同時更新による上書きを防ぐ仕組みも必要です。
- 版と適用日：台帳、様式、対応表、転記プログラムを組み合わせて保存し、どの版から生成したか追えるようにする。過去の提出書類は当時の状態で保管する。
- 承認：作業版と承認済みの書類を区別し、確認前のものを提出しない。承認後に元データが変わった場合は再生成・再確認する。
- 障害対応：失敗時は確定処理を止め、未完了の出力を区別する。バックアップから戻せることを確認し、復旧できなければ従来の作成方法へ戻す。
- 様式変更：改訂時は項目対応と検査を見直す。法令や提出条件の変更は担当者が根拠を確認してから反映する。
- 保存と廃棄：保存先、バックアップ先、保管期間、廃棄を判断する担当者を決め、試作データと実業務データを分ける。
原本を残した作業用コピーに加え、障害や誤削除に備えて別の場所にも複製を保管するバックアップが必要です。ファイルを共有フォルダへ置くだけで、権限管理や承認の仕組みが完成するわけではありません。実データで運用する前には、ファイル操作、外部通信、入力値の扱いを含め、実装に応じたセキュリティ確認も行います。
8．AIを使い、法改正に伴う文章の変更・追加・削除へ広げる
基本の転記が確認できたら、「適用日以降の料金だけ変える」「関連する書類の更新候補を一覧にする」といった機能へ広げられます。ただし、「制度が変わったので全部直して」という指示だけでは、対象、根拠、適用日が不足します。
改正資料と対象サービス、適用日、現在の書類を示し、Codexには影響する項目・文章の候補と理由を整理してもらいます。例えば、説明方法が変わった箇所は文章の変更、新しく説明が必要になった事項は追加、適用されなくなった記述は削除候補として分けます。これは対応方法の例で、特定の制度改正を示すものではありません。
返却結果は「対象書類・現在の記述・変更／追加／削除の案・根拠資料の該当箇所・適用日・未確認事項」の形にそろえると、担当者が照合しやすくなります。関連する案内文や契約の添付資料にも同じ説明があれば、それぞれの読者と用途に合う表現を検討できます。
担当者が根拠と採否を確認した後、作業版に反映し、変更前後の差分と書類間の整合性を確かめます。計算ルールや対応表の修正も必要なら、文章と併せて確認します。AIによる文章の見直し支援と、人による制度の解釈・適用判断を組み合わせる運用にします。
関連書類を抽出できる範囲は、登録済みの書類と把握済みの対応関係に限られます。未登録書類や、記録されていない条件まで漏れなく把握する保証はありません。必要な届出、説明、同意などの手続きも、書類の文言を変えるだけで完了するものではありません。
9．最初の試作を始める前のチェック
- 繰り返し入力している情報と、対象の書類を2〜3種類選んだ。
- 実情報を架空データに置き換え、本番とは別のフォルダを用意した。
- 同じ名称でも意味の違う項目を分け、転記先を確認した。
- 原本を残す場所、出力先、変更記録、失敗時の戻し方を決めた。
- 必要なソフトと利用条件を確認し、確認担当者を決めた。
- 最初の成功条件を「電話番号一つが指定した3書類へ正しく反映される」と具体化した。
最初にCodexへ依頼するのは、手元の架空データの書類を調べ、共通項目と違いを示すところまでで十分です。その結果を確かめてから、小さな転記処理を作ります。自分の業務で何を確認すべきかが分かる範囲から始めてください。
プロジェクトの準備、作業の分割、結果の確認、権限の考え方を見直す場合は、Codex初心者ガイドへ戻れます。
参考資料と確認範囲
OpenAI公式資料の確認日：2026年10月27日。ローカルフォルダを使うプロジェクトと作業範囲の説明は、OpenAI公式「Projects and chats」を参照しています。図表、項目対応、試作手順は本記事の構築提案です。個別の行政様式・制度・製品の対応状況、生成プログラムの実動作は未検証です。
関連リンクは本文中の用語リンクを参照してください。