生成AIプロンプトを属人化させない、AI駆動開発の版管理術

朝の八時半、オフィスの窓から淡い光が差し込んでいた。空調の低い音に、キーボードをたたく音が重なる。業務改善担当の真帆は、温かい紅茶を机の端に置き、ブラウザのChatGPTに報告書の下書きを頼んでいた。

真帆は、誰かに頼まれるとすぐに手を動かす人だった。部署の人が困っていれば、表計算の整理も、資料の見直しも引き受ける。最近は、文章を整える作業を生成AIに手伝ってもらい、空いた時間で業務の流れを考えていた。

「先月の問い合わせ件数をもとに、報告書の下書きを作って。事実と推測を分けて、最後に確認が必要な点を並べて」

画面の中で、ChatGPTが文章を組み立てていく。真帆は出てきた文を読み、数字が元の表と合っているかを確かめた。言い回しを少し直して、いつものフォルダに保存しようとしたとき、ファイルの一覧が目に入った。

「報告書用」「報告書用_修正版」「報告書用_最終」「報告書用_本当の最終」。似た名前のファイルが、縦に並んでいる。どれも自分で作ったものなのに、名前を見ただけでは、いつ何を直したのか思い出せなかった。

真帆はマウスを握り直し、いちばん下のファイルを開いた。文章の最後には「出典を必ず確認すること」と書かれている。けれど、その一つ前のファイルにも同じ指示があり、さらに前のファイルには「出典がない場合は、その旨を書く」とあった。

「この二つ、どこが違うんだっけ……」

小さくつぶやいたとき、背後から椅子を引く音がした。営業部の健太が、片手にノートパソコンを抱えて立っていた。急いでいるようで、肩から下げた社員証が歩くたびに揺れている。

「真帆さん、先月使った、出典を確認するプロンプトを貸してくれる？」

「出典を確認するプロンプト……。報告書に入れる文章の根拠を、AIにたずねるお願い文のことだよね」

「そう、それ。今朝、取引先向けの資料を作るんだ。前に真帆さんが使っていたものなら、確認漏れが少なかったから」

真帆はすぐに返事をしようとした。けれど、指はキーボードの上で止まった。先月使ったものが、どのファイルなのか分からない。最近、言葉を直したものを渡すべきか、実際にうまく動いた古いものを渡すべきかも決められなかった。

「少し待って。たぶん、ここにあるはずだから」

真帆はデスクトップの「業務改善」フォルダを開いた。そこには「AI活用」「報告書」「共有用」「一時保存」というフォルダが並んでいた。「AI活用」の中には、さらに「試す」「使った」「あとで整理」と書かれたフォルダがある。

「あとで整理」は、半年前から名前が変わっていなかった。真帆は苦笑しながら開いた。テキストファイル、Wordファイル、メモのコピーが混ざっている。ファイルの更新日は表示されるが、なぜ更新したのかまでは書かれていない。

健太は隣で画面を見つめた。

「この『出典確認_改』は？」

「たぶん、文章を短くした版。でも、短くした理由は……たしか、回答が長すぎたから」

「じゃあ、この『出典確認_改2』は？」

「それは……同じ日に直したかもしれない」

真帆はファイルを開き、二つの文章を並べた。片方は「根拠となる資料を示してください」。もう片方は「回答に使った情報源と、確認できない点を分けて示してください」だった。違いは分かったが、どちらが健太の仕事に合うのか、自信を持って言えなかった。

「この前、共有フォルダに置いた覚えはない？」

「見てみるね」

共有フォルダには、「報告書用_最終」と「報告書用_本当の最終」があった。真帆は眉を寄せた。自分のパソコンにあるものと、共有フォルダにあるものが同じかどうかも分からない。誰かが少し直した可能性もあったが、変更した人の名前や理由は残っていなかった。

健太は急かさなかった。けれど、ノートパソコンの時計は九時を過ぎている。真帆は「本当の最終」を開き、健太に渡そうとした。その瞬間、ファイルの中に赤い文字で「テスト中」と書かれているのを見つけた。

「待って。これは使わない方がいいかも」

「じゃあ、どれなら大丈夫？」

「……今、確認する」

真帆は過去のメールを検索した。件名に「AI」「報告書」「プロンプト」と入れたが、似た文章がいくつも見つかった。本文には「少し修正しました」「こちらを使ってください」とだけあり、何を変えたのか、どの資料で試したのかは書かれていない。

健太は画面から目を離し、静かに言った。

「真帆さんがいない日に、これを使いたくなったら、僕はどれを選べばいい？」

その問いに、真帆はすぐ答えられなかった。自分なら記憶をたどれる。けれど、健太にはその記憶がない。文章を渡すだけでは、使い方も、注意する場所も、一緒には渡らない。

窓の外で、車の走る音がした。真帆は画面に並ぶ「最終」の文字を見つめた。プロンプトは、AIへのお願い文にすぎないと思っていた。けれど、直した人の頭の中に理由まで隠れていると、チームの誰も安心して使えない。

「プロンプトは文章なのに、なぜこんなに引き継ぎにくいんだろう」

真帆のつぶやきは、朝のオフィスの小さな音に混ざった。健太は返事をせず、空いた画面を見ながら、真帆の机の奥にある「あとで整理」フォルダを指さした。そこには、まだ名前のない改善の種が、静かに眠っていた。

火曜の午後、健太はChatGPTを使い、公開情報の出典を確認する資料を作っていた。真帆から届いたファイルを開き、調査した内容を一つずつ貼り付けていく。画面の隅には、「報告書用_修正版」という名前が残っていた。

「真帆さんが送ってくれたから、これが今の版だよね」

プロンプトには、調べた情報の要約と、最後に出典名とURLを付けるよう書かれていた。健太はその指示に沿って、資料の表を整えた。見た目はきれいだったが、出典が一次情報かどうか、本文のどの部分を根拠にしたか、確認した日がいつかは書かれていなかった。

「出典の欄は、これで大丈夫かな」

健太は少し迷った。それでも、会議の開始時刻が近づいていたため、資料をPDFにして会議室へ向かった。真帆は別の打ち合わせ中で、プロンプトについて聞き直す時間はなかった。

会議室では、部長の里見が資料をめくっていた。窓から入る午後の光が、机の上の紙を白く照らしている。里見は最後のページで手を止め、出典欄を指で軽くたたいた。

「この出典の確認方法は、いつ、なぜ変わったのかな」

健太は背筋を伸ばした。資料にはURLが並んでいたが、どれが新しい確認方法なのかは分からない。隣に座った真帆も、紙面を見たまま黙っていた。

「たしか先週、出典の扱いを直したはずです」

真帆はそう答えた。けれど、声の最後が小さくなった。変更前の文章も、直した理由も、すぐに示せる場所にはなかった。

里見は責めるような顔をしなかった。資料を机の中央に置き、健太と真帆の方へ向き直った。

「直したことは覚えている。でも、どこをどう直したかは残っていない、ということだね」

「はい。たぶん、そうです」

会議はいったん止まった。健太は資料の一部を開き、手作業で確認項目を足すことになった。大きなやり直しではないが、参加者の予定を少しずつ後ろへ動かすことになった。

真帆は席を立ち、共有フォルダを開いた。そこには「出典確認プロンプト」「出典確認プロンプト_改訂」「報告書用_最終」「報告書用_本当の最終」という名前のファイルが並んでいた。同じような文面が入っているのに、更新日だけが違っていた。

「これと、これ。どちらが先かは分かります。でも、どちらを使うべきかは分かりません」

健太が画面をのぞき込むと、ファイルの中には以前の指示が残っていた。「出典名とURLを末尾に記載する」という一文だ。現在必要になった「根拠箇所と確認日を示す」という項目は、別のファイルにしか見当たらなかった。

真帆は社内チャットを検索した。検索欄に「出典」「確認」「プロンプト」と入れるたび、過去の投稿が画面に浮かんだ。ある投稿には新しい文面が貼られ、別の投稿には古い文面が添付されていたが、どちらにも変更理由は書かれていなかった。

「この投稿のあとに、私が『直しました』と書いています」

「でも、何を直したかは書いていないね」

「はい……」

次に、真帆は自分の個人メモを開いた。そこには、会議の前日に急いで書いた短い言葉が残っていた。「出典のところ、少し修正。次回から新しい方」。日付はあったが、変更前の文章も、修正後の全文もなかった。

健太は、手元の資料と画面を交互に見た。自分が古い版を選んだのか、真帆が古い版を送ったのか、それさえ決められない。誰かの間違いというより、同じものが別々の場所で少しずつ変わっていた。

「プロンプトの中身だけを置いても、途中の道が見えないんですね」

里見は会議室のドアの近くで、三つの画面を静かに見ていた。共有フォルダにはファイルがあり、チャットには断片があり、個人メモには記憶の手がかりがあった。けれど、それらは一つの履歴になっていなかった。

「誰が作ったかだけでは足りない。何のために作り、誰が見て、どう直したかまで残さないと、次の人は選べないね」

真帆はうなずいた。自分の頭の中ではつながっていた記憶が、画面の外へ出た瞬間にほどけていた。健太は資料の出典欄に、根拠箇所と確認日を追記し始めた。

「まず今日は、この資料を確認できる形に直します」

「そうしよう。プロンプトの話は、資料が落ち着いてからでいい」

里見の言葉で、会議室の空気が少しやわらいだ。健太が修正した資料を再びChatGPTの出力と照らし合わせる間、真帆は散らばったファイル名を紙に書き出した。そこには、古い版と新しい版の境目を探すための、最初の小さな線が引かれていた。

夕方、オフィスの窓が茜色に染まるころ、里見は真帆の隣の席でノートパソコンを開いた。画面にはGitHubの新しいリポジトリ作成画面があり、真帆は少しだけ身を乗り出した。

「今日は、プロンプトを置く場所を作ろう」

真帆は、先月のファイル名を思い出した。「報告書用」「報告書用_修正版」「報告書用_本当の最終」が頭の中で重なっている。健太が困っていた出典確認用のプロンプトも、どこにあるのか、まだはっきりしなかった。

「GitHubは、プログラムを書く人だけの場所ではないんですか？」

「そう思われがちですね。でも、GitHubは文章の変更履歴を置く棚にもできます。リポジトリというのは、その棚の名前です。ファイルと、その変更の記録を、ひとまとめに置けます」

里見は、リポジトリ名の欄に prompt-assets と入力した。続けて、説明欄に「業務で使うプロンプトの保管場所」と書き、共有範囲を確認してから作成ボタンを押した。白い画面に、まだ何も入っていない小さな棚が現れた。

「まずは、プロンプト本体を置きます。ただの長いメモではなく、YAMLという形にします」

里見は、YAMLを「項目名と中身を、読みやすく並べる書き方」と説明した。目的や入力、出力形式、注意点を分けておけば、初めて見る人でも、どこを読めばよいか迷いにくいという。

「ファイル名は primary_source_finder.yml にしましょう。出典を確認するためのプロンプトだと、名前だけでわかります」

画面に、次の設計図がゆっくり現れた。

name: primary_source_finder
purpose: 情報の一次資料を探し、出典を確認する
input:
  - 調べたい主張
  - 調査対象の期間
output:
  - 資料名
  - 発行元
  - URL
  - 主張を裏づける箇所
cautions:
  - URLと内容を人が確認する
  - 顧客情報や未公開情報を入力しない

真帆は、以前のプロンプトを思い出した。「出典を探して」とだけ書いていた。里見は、短い指示よりも、対象や目的、出してほしい形を具体的にした方が、AIの返事もそろいやすいと話した。

「プロンプトは、AIへの指示や質問の文章全体です。ここにあるのは、指示そのもの。毎回の入力は、調べたい主張を渡す部分です」

次に里見は、同じ棚に README.md というファイルを作った。そこには、このプロンプトをどの業務で使うか、入力欄に何を書くか、出力されたURLと根拠をどう確認するかを記した。顧客データや契約書の内容を入れないことも、赤い文字ではなく、落ち着いた注意書きとして加えた。

「プロンプト本体は、指示そのものです。READMEは、使い方の説明です。役割を分けると、全部を一つの長いメモに詰め込まずにすみます」

「変更の理由は、どこに書くんですか？」

里見は、保存ボタンの横にあるコミット欄を指した。コミットは、ファイルを保存した時点の記録だという。たとえば「出典確認の手順を追加。会議で根拠の確認が不足したため」と書けば、文面だけでなく、なぜ変えたのかも後からたどれる。

「本体、README、コミット履歴。この三つを分けておくと、プロンプトの現在の形、使い方、変更の道筋が見えます」

真帆は、画面の右側に表示された差分を見た。追加された行は緑色で、消えた行は赤色で表示されている。古い版と新しい版の違いが、ファイル名を何度も開くより、ずっと簡単にわかった。

里見は、参考資料の欄にIPAの「テキスト生成AIの導入・運用ガイドライン」を登録した。総務省の自治体向けAI導入ガイドブックや、千葉県のプロンプト集も、使い方と確認の考え方を学ぶ材料になると話した。

「生成AIは、出した答えをそのまま使うものではありません。事実や表現を人が確認する手順まで、READMEに残しておきましょう」

プロンプトをチームの資産として管理する考え方は、PromptLayerの説明にも見られた。そこでは、プロンプトを一か所に集め、版ごとの差分や変更理由を確認し、必要ならテストする仕組みが紹介されている。里見は、専用のサービスをすぐ導入しなくても、まずGitHubで同じ考え方を小さく始められると言った。

「最初から完璧な仕組みはいりません。誰が見ても使える形で、一つ置いてみることが大切です」

真帆は、健太が探し続けていた古いファイルを思い浮かべた。もし、あのプロンプトに目的と注意点があり、変更理由まで残っていたら、会議で確認に迷うことはなかったかもしれない。

「私も、やってみます」

真帆は自分の名前をレビュー担当として記し、最初のコミットを作った。画面に「出典確認用プロンプトを追加」という記録が残る。夕暮れの棚に、小さな設計図が一枚、静かに収まった。

その夜、真帆は健太にリンクを送った。健太は共有フォルダを探す代わりにREADMEを開き、入力例を試した。翌朝の机には、「どこを直したか」がわかる新しい版が、二人の共通の道具として置かれていた。

真帆たちは、GitHubで出典確認用プロンプトの版管理を始めた。今日はYAMLファイルを置き、最初のコミットを作る日だ。朝の光が画面に差し込み、白いリポジトリが小さな作業台のように見えた。

里見は隣の席で、GitHubのリポジトリを開いた。真帆は prompts/source-check.yml という名前を入力し、Add fileからUpload filesを選び、前章で整えたYAMLを画面へドラッグした。内容は公開情報だけを使い、出典のURLを確認し、確認できないことは「不明」と書く指示だった。

「ファイルを選んだら、下の欄に変更の説明を書きます。最後にCommit changesを押せば、変更が記録されます」

真帆は少し息を止めて、メッセージ欄に「修正」と入力した。緑色のボタンを押すと、ファイルは無事に main ブランチへ入ったが、胸の奥には小さな引っかかりが残った。

「できました。コミットは、変更した内容を置く場所ですよね？」

「惜しいです。コミットは、実際の変更を残すしおりです。『何を、なぜ直したか』が後から分かる言葉を、そのしおりに添えます」

里見が履歴を開くと、短い「修正」の文字が一つだけあった。健太が画面をのぞき込み、先月の報告書と今月の出力を見比べた。

「これでは、出典の確認手順を増やしたのか、表の見た目を変えたのか分かりません。未来の自分が、迷子になりそうです」

里見はファイルを消してやり直すのではなく、新しい変更を小さく加えるよう促した。真帆はYAMLの steps に「回答中の主張ごとに、公式ページなどの出典を照合する」と一行足し、出力形式を表から箇条書きに変えた。

「出典確認の手順を追加、出力形式を表から箇条書きに変更、でどうでしょう」

「いいですね。変更内容と理由が一緒に見えます。確認者が読みやすくするため、と書けば、次の人も意図をつかめます」

真帆はコミット欄に 出典確認の手順を追加し、出力形式を箇条書きに変更 と入力した。最初の「修正」は失敗ではなく、書き方を学ぶためのしおりになり、履歴には二つの段階が並んだ。

健太は、出典URLが空のときに警告を出す改善案を話した。里見は main のファイルを直接書き換えず、feature/source-warning という作業用ブランチを作る手順を示した。

「改善案はここで作り、コミットしたら、Compare & pull requestを押します。プルリクエストは、変更案を確認してもらう窓口です」

健太はタイトルに「出典URLが空の場合の注意を追加」と書き、本文に変更理由、確認した入力例、見てほしい点を記した。里見が差分を開くと、追加した一行が色つきで表示され、真帆も変更前後を並べて読めた。

「Issueとコミットと、プルリクエストは同じものだと思っていました」

「Issueは、困りごとや相談を置く掲示板です。コミットは実際の変更を残すしおりで、プルリクエストは、その変更案を確認してもらう窓口です。役割が違うから、相談から改善までの道筋が見えます」

健太は先にIssueへ「出典URLがない回答を見つけた。警告を表示したい」と書き、その番号をプルリクエストに添えた。改善案が承認されるまで main は変わらず、承認後にMergeする流れも、三人で確かめられた。

次に、真帆はGitHub Pagesの設定画面を開いた。公開ボタンに指を伸ばしかけたとき、健太がREADMEの例に過去の依頼文を貼りかけていたことに気づいた。

「そこには顧客名とメールアドレスが残っています。公開前に消しましょう」

里見は画面を閉じ、顧客データ、契約書の内容、未公開製品の情報、個人情報はプロンプトにもサンプルにも入れないと確認した。例は「顧客A」や [商品名] に置き換え、社内だけで使うプロンプトはPrivateのリポジトリに分けることにした。

READMEには、利用目的、入力してはいけない情報、想定する出力形式、人が確認してから使うこと、利用モデル、版番号、更新日を書いた。里見は、プロンプトを共有資産にするには、文面だけでなく、使う場所と確認する人も残す必要があると話した。

「IPAのテキスト生成AIの導入・運用ガイドラインにも、導入後の確認や運用の大切さが書かれています。デジタル庁の業務利用技術検証・環境整備報告や、観光DXにおける生成AI活用の実証調査結果も、試して、確かめて、整える背景になります」

真帆は、最初から全部を公開しようとするのをやめた。まずは安全な出典確認用プロンプト一つだけを公開用リポジトリに置き、GitHub PagesはREADMEを案内する場所として使うことにした。

設定で Settings、Pages、Deploy from a branch の順に選び、main とルートフォルダを指定する。保存すると、しばらくして確認用ページが表示されたが、READMEの見出しが一つ崩れていた。

「公開できたのに、見た目が少し読みにくいですね」

「それもIssueに書きましょう。小さな不具合を見つけ、直し、コミットに残す。その繰り返しで仕組みが育ちます」

真帆はIssueに「READMEの見出しを修正」と書き、健太のプルリクエストを承認した。画面の公開ボタンの前には、まだ慎重さが残っていたが、何を確認すれば安全に進めるかは、三人の履歴の中に静かに残っていた。

数日後、チームの共有画面にあるGitHub Pagesのカードから、健太は出典確認用プロンプトを開いた。以前なら真帆の机まで歩き、どのファイルを使うのか聞いていた時間だった。

画面には、プロンプトの説明とコピーボタンがあった。健太がボタンを押すと、YAMLで整えられた本文がクリップボードに入った。横には、使う前に準備する入力と、作業の順番がREADMEに書かれていた。

「報告書の草稿と、確認したい資料を用意する。顧客データや未公開情報は入れない。出力された内容は、最後に人が確認する」

健太は声に出さず、READMEを上から読んだ。資料の名前、確認したい主張、根拠のリンクを入力する。出力は、確認済み、確認が必要、根拠が見つからない、という区分に分かれる手順だった。

コピーした本文をChatGPTの入力欄に貼る前に、健太の手が止まった。手元の資料には、社内だけで使う情報が少し含まれていた。

「この資料は、名前を伏せた要約なら使えますか？」

真帆は画面をのぞき込んだが、すぐには答えなかった。

「READMEの入力禁止情報のところを、もう一度見てみて。判断の基準が書いてあるよ」

健太は該当する行を読み直した。個人を特定できる情報や、公開前の内容は入力しない。必要なら、情報を置き換えてから使う。迷うときは、確認担当に相談する。短い文が、次にすることを示していた。

真帆は隣で手順を読み上げなかった。健太が自分で入力を整え、コピーボタンを押し、出力を人の目で確認するまでを進めた。以前なら、真帆の記憶にある細かな注意を聞かなければ、作業の入口にも立てなかった。

「ここまで、自分で進められました」

健太の声には、戸惑いよりも確かな手応えがあった。真帆は小さくうなずき、画面のカードを見た。

そのころ、少し離れた席で里見がGitHubの変更履歴を開いていた。出典確認の条件が追加されたコミットと、出力形式が変わったコミットが、順番に並んでいる。ファイルの差分だけでなく、変更理由とレビューの記録も残っていた。

「この条件は、どうして追加されたんですか？」

履歴には、根拠のリンクがあるだけでは、本文のどの主張を支えているのか分かりにくかったため、と書かれていた。出力形式を区分ごとに分けたのは、確認が必要な箇所を見落とさないようにするためだった。

里見は画面を閉じずに、ひとつ前の版も開いた。前の本文と今の本文を見比べると、どこが変わり、なぜ変わったのかが追えた。記憶をたどらなくても、プロンプトの成長が見えるようになっていた。

「これなら、出力が変わったときも、理由を探せますね」

午後、健太は新しい改善案をGitHubのIssueに書いた。資料に複数の根拠がある場合、根拠ごとの確認結果を見やすく分けたい、という提案だった。

「Issueは、直したいことを置く札です。プルリクエストは、その案を実際の変更として見てもらう窓口です」

健太はそう書き添え、画面を真帆の席へ向けた。真帆の受信欄には、健太からのプルリクエストが届いていた。

以前の真帆なら、まず自分のフォルダを開き、古いファイルを探していた。今は、Issueの背景を読み、変更されたYAMLとREADMEの差分を見て、確認すべき点をコメントに残している。誰かの頭の中に隠れていた手順が、プロンプト本体、説明文、コミット、Issue、プルリクエストに分かれて見えていた。

夕方、新しく作業に加わった美咲が、健太に声をかけた。

「出典確認のプロンプトは、どれを使えばいいですか？」

健太は自分のフォルダを開かなかった。GitHub Pagesのカードを指し、READMEの入力手順と、現在の版を確認する場所を伝えた。美咲はカードを開き、画面を読みながら準備を始めた。

その様子を見ていた真帆の机には、かつて並んでいた「報告書用_最終」というファイル名がなかった。代わりに、ブラウザの同じ棚から、同じプロンプトと履歴が取り出されていた。

「次の改善案も、Issueに書いておきます」

健太がそう言うと、真帆は笑ってうなずいた。説明を一人で抱える仕事は、少しずつ、みんなで履歴を育てる仕事に変わっていた。

一日の終わり、真帆は新しい改善案をコミットに残し、静かなオフィスで仕事を終えようとしていた。朝のように、画面の中でファイルの名前が迷子になることは、もうなかった。

窓の外は薄い青色だった。真帆はGitHubのリポジトリを開き、報告書用プロンプトのREADMEに、利用時の注意書きを加えた。顧客データや契約書の内容、未公開の情報は入力しないこと。そして、ChatGPTの出力は、そのまま使わず、事実と出典を人が確かめることだった。

「前は、こういう注意も真帆さんの頭の中にあったんですね」

後ろから健太の声がした。真帆は画面を見たまま、少し笑った。

「うん。今はREADMEに置いておけば、使う人が同じ場所で確認できるから」

保存された変更を開くと、どこに文章が加わったのかが色分けされていた。真帆は内容を読み直し、業務の担当者にも意味が伝わるかを確かめた。

画面の下にある入力欄へ、真帆はゆっくり文字を打った。

「利用時の確認項目を追加」

「コミットって、変更を名前つきで残す印みたいなものですよね」

「そう。あとで見た人が、何を変えたのか想像しなくてすむの」

GitHubの画面に、そのメッセージが表示された。変更した人と時刻も並び、READMEの前の版へ戻る道も残っていた。

そのころ健太は、GitHub Pagesのカード一覧を眺めていた。報告書用の隣に、会議メモの整理、問い合わせの分類、営業提案書の下書きが、用途ごとに並んでいる。

健太は「問い合わせ分類／レビュー済み」と書かれたカードを開いた。READMEに書かれた入力例を読み、使ってはいけない情報を確認してから、自分の業務に合わせて試し始めた。

「このプロンプト、最初の一行だけで使えるんですね」

「中の指示や例は、もうテンプレートに入っているから。迷ったら、READMEの使い方に戻ればいいよ」

少し離れた席では、里見がGitHub Issueを開いていた。そこには「出力の表現が部署によって違うときは、どの例を足すか」という質問が残っている。里見は画面の端に小さくメモをした。

「次は、部署ごとの入力例を比べてみよう」

誰かの疑問は、誰かの記憶にしまわれなかった。Issueの中に残り、次の修正を知らせる小さなしおりになっていた。

真帆はふと、自分のPCのフォルダを思い出した。「報告書用」「報告書用_修正版」「報告書用_最終」と並んでいたファイルは、今も消えてはいない。けれど、最新版を探すために一つずつ開く必要は、もうなかった。

画面には、プロンプトの本文だけでなく、使い方、変更の理由、確認した人、周囲からの提案が、それぞれの場所に残っている。個人の記憶に頼っていた仕事は、GitHubの棚に、名前のついたカードとして静かに並んでいた。

真帆は席を立つ前に、もう一度コミットの履歴を確認した。新しい注意書きと、健太が開いた別のカードと、里見のメモが、明日の作業へ続く細い道のように画面に残っている。

照明を落とすと、GitHub Pagesの一覧だけが淡く光った。翌朝、誰かがこの画面を開いたとき、迷わず次のプロンプトを選べるように、真帆はノートパソコンを静かに閉じた。