第22話 速すぎる相棒

　五月十五日。月曜日。

　初夏の入口の朝、空の高さが少しだけ変わったことに、桜子は改札を抜けたところで気がついた。街路樹の若い葉が、まだ薄いけれど、はっきりと緑になっていた。

　自分の席でノートPCの蓋を開けると、開発Slackのいちばん上に、鈴木の長めの投稿が、そのまま固定されていた。

@suzuki-kenichi: 皆さんおつかれさまです。
先月のLT会でお約束していた「ChatPort 利用ガイドライン」の
暫定版を、本日付で運用開始します。法務/セキュリティと擦り合わせた骨子です。

1. 顧客情報、本番データ、未公開資料は入力しない
2. ChatPort が書いたコード・文章は、PR本文にその旨を明記
3. ChatPort 由来の成果物も、通常どおりレビューを受ける
4. 業務利用の対話履歴は、社内wikiの共有ページに保存する
5. ChatPort だけを根拠にした判断はしない。必ず人の確認を挟む

疑問・追加要望は、このスレッドにぶら下げてください

　桜子は、鞄から観察ノートを取り出した。

　このノートに行を足すのは、これで七回目になる。四月十一日、翔太のLTのあとにカフェで始めた #001 から、四月の後半には境界の壊れ方をさらに何通りか、月末には指示の粒度を変えた比較、五月に入ってからは、無料アカウントで対話履歴をどう残すかの試行と、小さな一行を重ねてきた。ちょうど今日で、#007 に届く。

　桜子は、ガイドラインの五項目を、要点だけ、短く書き写した。

ChatPort 観察ノート #007
2023/05/15
- 社内ガイドライン暫定版、発効
- 1. 入力禁止情報
- 2. AI生成の明記
- 3. レビュー必須
- 4. 対話履歴の社内共有
- 5. 単独根拠禁止

　書き写した五項目の余白に、桜子は、心の中の予感を、一行だけ、添えた。

　（中村くんは、もう、これに沿って、動き始めてる）

　その予感は、その週のうちに、事実の輪郭を、しっかりと持ち始めた。

　翔太のPRは、ガイドラインが出た週の水曜日、五月十七日の夕方から、上がり始めた。

#342 feat: bulk export of inquiries to CSV (AI-assisted)

　最初の一本にはレビュアーから数コメント。翔太は翌朝までに指摘を反映し、境界テストを一件だけ足して、木曜の午後には ready-for-review へ戻した。

　そのままの勢いで、翔太は金曜のうちに次のブランチを切っていた。週明けの二十二日月曜、

#347 feat: saved-search presets with shareable URL (AI-assisted)

　が続く。共有URLの発行順序と、期限切れの扱いで、遥からの指摘が二回。翔太はそのつど、対話履歴の該当行を wiki に追記し、修正コミットの粒度を細かく保った。

　そして二週目の水曜日、五月二十四日の午前中に、

#353 feat: notification email digest (AI-assisted)

　が ready-for-review になった。ガイドラインが出てから、まだ二週目の半ばで、中規模のPRが三本。普段の翔太の倍近い流量だった。

　どのPRにも、本文の冒頭に、ガイドライン第2項に沿った注記があった。

Note: ChatPort を調査・草案・実装補助に利用しました。
対話履歴: wiki/ai/chatport-history/nakamura-2023-05.md
最終判断とコードの責任は、著者 (中村翔太) が持ちます

　三本ともコミットは細かく分かれていて、「AI草案の受け入れ」「変数名の修正」「ログ整備」「エラーハンドリング」「境界テスト追加」と、ひとつずつ役割が違った。コミットメッセージは、いつもの翔太のそれより、ほんの少しだけ長い。レビュアーへの配慮の分だけ、丁寧に見えた。

　つまり、翔太が ChatPort から借りているのは速度の部分だけで、品質の部分は、いままで通り、自分の手で仕上げていた。

　（ちゃんと、してる）

　桜子は、正直に、そう思った。同時に、

　（ちゃんと、してる、まま、速い）

　とも、思った。

　二週目に入ってから、桜子は自分の担当タスクの手を止めずに、昼休みと合間の時間で、翔太のPRを、上がってくるたびに、自分のエディタで開いた。

　差分は、それぞれ数百行。翔太が対話履歴を社内wikiに公開しているおかげで、ChatPort に何を渡し、何を受け取り、どこを書き直したかが、順を追って読める。桜子は、その履歴と、コミット単位の差分を、観察ノートに書き写していった。

ChatPort 観察ノート #008
2023/05/22
翔太くんのPR #342 (bulk export) の内部構造

- 仕様理解: 既存の Export API の挙動、Slack経由で要件整理
- 設計草案: 「CSVで数万件をメモリに載せずに出す実装案」を投げ、
  ストリーミング案が返る。返ってきた案を、翔太くんが調整
- 実装: 雛形のクラス/関数は ChatPort 生成、変数名・ログ・
  エラーハンドリングは翔太くんが自分の手で修正
- テスト: parametrize のパターンを翔太くんが書いた上で、
  エッジケースの洗い出しだけ ChatPort に追加投げ
- レビュー: 山下さんが3コメント、鈴木さんが2コメント、
  早瀬さんが1コメント、わたしが1コメント。翌朝までに全反映
- 所要時間: 着手から ready-for-review まで、およそ1.5日

観察:
- 翔太くんは ChatPort を「下書き生成装置」として使っている
- 下書きを、翔太くんの頭で、現場の言葉に、書き直している
- 速さは、下書きを書く時間が、ほぼ、消えている分。
  仕上げは、手で、いままで通り
- 「仕上げ」がなければ、たぶん、数百行が浅く広がって、
  レビューで弾かれていた
- 履歴の頭に、毎回、同じ「前提」のブロックがある。定型文、かな

　同じ手つきで、#347 と、水曜の朝に上がった #353 も、続けて観察した。結論は、どれも、同じ形をしていた。翔太は、ChatPort の出力を、自分の頭の中で、もう一度、現場の言葉に翻訳していた。翻訳のぶんの負荷は、翔太が引き取っていた。

　ただ、その翻訳が、三本とも、なぜあれほど短い時間で済んでいるのかは、まだ、見えなかった。

　一方、桜子の担当タスクは、通常ペースだった。

　三月の年度末リリースの日、千葉ハートフルケアの高木さんからメールで届いた「顧客企業欄が空だと、一瞬、迷う」という改善のタネ。空表示そのものは、桜子自身が三月に本実装した、フォールバックの表示側だった。これを、情報設計から組み直す仕事は、業務理解が厚く必要で、急げば必ず浅くなる類のものだった。

　五月二十四日水曜日。夕方、十八時前。

　桜子は、自分の担当のドキュメントと、翔太のPR活動のSlack通知を、交互に見ながら、指先が、少しだけ、冷たくなるのを感じた。

　（わたしも、ChatPort、業務に使ってみよう）

　使うこと自体は、ガイドラインで禁止されていない。第1項の入力禁止情報を避け、第4項の「対話履歴を社内wikiに共有」と、第5項の「単独根拠にしない」を守れば、使ってよい範囲だった。

　定時までまだ少しある時間帯に、桜子は、ChatPort の画面を、開いた。

　顧客名、社内固有名、未公開コード、実際の顧客運用の細部は、一切、入れない。代わりに、公開情報の範囲で通る、一般化した書き方で、こう打った。

架空のBtoB向け問い合わせ管理Webアプリで、
顧客企業マスタ欄が外部API失敗時に空表示される仕様がある。
ベテラン利用者から「一瞬迷う」との声。
この欄の情報設計(IA)を、再設計したい。
フォールバック時・平常時・回復直後の3状態の表示を、
ユーザーの業務中断を最小化する方針で、3案、
メリット・デメリット・段階導入の順序つきで、提案して。
公開情報の範囲で

　数秒、画面に考え込むアイコン。そして、整った三案が、流れるように返ってきた。

　（はやい）

シーン5　出力と、手触りの落差

　桜子は、三案を、上から下まで、読んだ。

　案A: フォールバック時に「この欄は一時的に取得できません」と明記 　案B: 過去取得値のキャッシュを表示し、「最終更新: X分前」を併記 　案C: フォールバック時は欄自体を畳み、クリックで展開

　どの案も、整っていた。文章は、流暢だった。

　けれど、桜子は、読みながら、三つのことに気づいた。

　ひとつめ。どの案にも、「業務中断を最小化する」の具体的な定義が、書かれていなかった。同じ画面を毎日見ているベテラン利用者にとっての「中断」と、月に一度しか触らない管理職にとっての「中断」は、たぶん、違う。ChatPort は、その現場のどちらも、見ていない。

　ふたつめ。どの案にも、ロールバックの記述が、ない。「Rollback手順がない変更は、出してはいけない」。去年の秋、休日のカフェで、遥が自分のノートごと静かに見せてくれた、あの個人原則が、この三案の中には、影の形すら、ない。

　みっつめ。段階導入の順序は、それらしく並んでいたが、今年の一月、リリース前夜の会議室で、桜子が自分でホワイトボードに並べた評価軸——業務影響、顧客説明、ロールバック可否、再発防止の成立度、営業コミットメント——には、どれも沿っていなかった。並んでいるのは、一般論の順序だった。

　桜子は、観察ノートに、こう書いた。

ChatPort 観察ノート #011
2023/05/24 18:35
高木さんの改善のタネを、一般化して投げてみた結果

- 案は、綺麗に出る
- ただし、わたしが一年でつくった判断軸は、
  出力の中に、ない
- 当たり前。ChatPort は、うちの障害報告テンプレも、
  Runbook も、わたしの観察ノートも、見ていない

対応策(仮):
- ChatPort の出力を、そのまま使わない
- 出力を、自分の判断軸で「翻訳」してから使う
- そのためには、プロンプトの側に、
  自分の判断軸の要点を、明示的に入れる必要がある

　対話履歴は、第4項どおり、wiki の自分のページに、貼った。三案は、使わなかった。持ち帰ったのは、自分の判断軸が出力の中にない、という気づきだけだった。

　（これは、中村くんが、やってたこと、かもしれない）

　桜子は、画面を閉じて、翔太が社内wikiに公開している対話履歴のページを、もう一度、開いた。

　プロンプトの最初のブロックに、翔太は、こう書いていた。

前提: 中小BtoB向けの一般的なWebアプリを想定。
コードレビュー必須、変更にはロールバック手順を併記、
境界条件(日付/数値/NULL/空集合)のテストを含める、
本番投入は段階導入を前提とする、
「AIが書いた」注記と対話履歴の保存を運用に含める

　顧客名や社内固有名は、どこにも、入っていなかった。翔太が入れていたのは、うちの現場で当たり前になっている「守り方の型」を、一般化した言葉に置き換えた前提だけだった。

　（中村くんは、うちの型を、外に出せる形に、翻訳してから、渡してる）

　桜子は、時計を見た。十八時四十五分。

　（今日は、ここまで）

　画面を閉じて、鞄にノートPCを戻す。続きは、頭を休めた明日の朝でいい。窓の外で、初夏の夕暮れが、まだ少しだけ明るかった。

　五月二十五日木曜日。朝。

　桜子は、翔太の席に、コーヒー片手に、寄った。

「中村くん、ひとつ、聞いてもいい？」

「どうぞ」

「速さの、中身、教えてほしい」

　翔太は、椅子を少しだけ、桜子の方に向けた。去年の夏、翔太のPRの速さに、追いつけない、と思うだけで、その速さの中身を翔太に聞きはしなかった日の、対称形だった。

「中身、というと？」

「プロンプトの最初のブロック、『前提』って書いてるところ。あれが、速さの核じゃないかな、と思って」

　翔太は、少しだけ、口角を上げた。

「うん。たぶん、そう。あれがあると、生成物が、最初から、うちで使える形に近く出る。ないと、綺麗だけど、浮いたやつが出る」

「あれ、中村くんがひとりで、作ったの？」

「四月、素の ChatPort で勉強してたころは、浮いた案ばっかり出てた。ガイドラインが出た週から、前提ブロックを、少しずつ足していってる」

「足してるのは、どこの言葉？」

「機密は、入れてない。うちの現場で当たり前になってる守り方を、一般化した形で、書き直してる。ロールバック手順を必ず併記、境界条件テストを含める、レビュー必須、段階導入。そういう、社外の記事にも普通に書いてある水準の言葉」

「その言葉、どこから引っ張ってきたの？」

　翔太は、視線を、少しだけ、上の方に外して、答えた。

「望月さんが一年目に書き残した、障害報告、Runbook、リリースチェックリスト。それから、望月さんが二月に、二案併記で通した、あのPRの本文。ああいうのを、自分でひととおり読み直して、機密の部分は削って、そこから使える型を、一般化して抜き出した」

　桜子は、目を、少しだけ、丸くした。

「……わたしの、あれ？」

「望月さんの文章、機密じゃない部分は、うちの守り方の教科書に近い。あれを自分の中で消化してから、外に出せる形に整えて、ChatPort の前提に置いてる」

「中村くん」

「僕、ChatPort で加速してるけど、加速の土台には、望月さんが一年でつくった型も、入ってる」

　桜子は、しばらく、何と返していいか、分からなかった。

　翔太は、軽く、肩を上げた。

「望月さんも、自分の判断軸で、前提、組むといい。たぶん、他の誰の真似より、望月さんの判断軸のほうが、望月さんに、合う」

　その言葉には、いつもの翔太の理屈っぽさの奥に、めずらしく、素直な音が、混ざっていた。

　五月二十五日。夕方。十八時二十分。

　桜子は、退勤前の残り時間で、観察ノートを、机の上に、開いた。

ChatPort 観察ノート #012
2023/05/25
- 翔太くんのプロンプト前提ブロック
  = 一年目にわたしが書き残したものを、翔太くんが読み直して、
    機密を抜き、一般化した形にしたもの
- 翔太くんの速さは、ChatPort の速さではなく、
  前提設計の速さ
- わたしも、自分の判断軸で、前提を書く
- 速さで追うのではなく、自分の判断軸を前提にして使う

　書き終えて、桜子は、ペンを置いた。

　窓の外を見ると、若い葉を増やした街路樹が、初夏の手前の光を、そのまま受けていた。風は、四月のあの日より、確かに一段、軽くなっていた。

　去年の夏、翔太と初めて同じ課題で競った日に、メモ帳に書いた「追いついたフリをするより、別の山を、ちゃんと登る」を、桜子は、もう一度、思い出した。今度のライバルは、翔太だけではなかった。画面の向こうにある一枚の白い窓も、同時に、相手になっていた。

　けれど、翔太のプロンプトの前提ブロックが、桜子が一年目に書き残したものの、一般化された姿だった、という事実は、ひとつだけ、静かな手応えを残した。

　桜子が一年目、ひとつずつ、テンプレや Runbook や二案併記の形で書き残したものは、この五月からの新しい道具の中にも、形を変えて、残っていた。

　（わたしの判断軸は、わたしの速さの、材料になる）

　明日からの桜子のプロンプトの、最初のブロックに、何を書くか。それを考える時間が、これからの桜子の、もうひとつの仕事になる。

　（次の観察は、自分の判断軸の、要約から）

　観察ノートの次のページを、桜子は、頭の中で、そっと、めくった。

　そのとき、開発Slackの端に、別チームから新しい AI-assisted のPR通知が、ひとつ、増えた。翔太の名前ではなかった。桜子は、今日は、そのリンクを開かなかった。

　鞄にノートを戻し、ノートPCの蓋を、そっと、閉じる。

　定時まで、あと、十分ほど、あった。