ChatGPTに自分用の週次レポートを書いてもらっている時に、文章について以下のように指摘した。
癖がわかってきた。 まず以下だけど
＞UberのLarge-Scale Automated 依存関係 Analysisは、
＞複雑なマイクロサービスメッシュで直接・間接依存を
＞継続的に把握し、失敗 impactを評価する仕組みを説明している。
読者の頭の中に「UberのLarge-Scale Automated 依存関係 Analysis」という語彙がなく、
それがなんであるかmental modelがないのに、
さも、それが読者にとって既知であるかのように 説明が始まっており読者を置いてきぼりにしている文章になってしまっている。
以下もそう
＞Datadogの9月15日の記事は、エージェント導入の議論を
＞「モデル・プロンプト・ツール」から「基盤処理能力」へ引き戻す点で重要である。
とあるが、同様に読者はその記事がどのようなものであるかを知らない。
だから本当は「Datadogの9月15日の記事 - [タイトル名]において[著者名]は[topic」について論じた。彼の主張の骨子はxxxである」みたいに書く必要がある。
全体的に「読者が何を知っていて何を知らないのか」に対する配慮が欠如している。
すると、以下のような返信があり大幅に文章の品質が改善された気がする。(主観)
その指摘で合っています。問題は単なる「日本語の自然さ」ではなく、文章設計上の前提が間違っていました。
前回の文章は、書き手側ではすでに調査を終えているため、「Large-Scale Automated Dependency Analysis」「Datadogの9月15日の記事」といった対象が頭の中に存在しています。その状態のまま書いているので、読者にも同じ文脈があるかのように扱ってしまっています。いわば、書き手の知識状態を読者に誤って投影しています。
文章論的には、これは「新情報を既知情報として提示している」問題です。読者の頭の中にまだ discourse referent が作られていないのに、その対象について評価や解釈を始めている。結果として、文法的には読めても、頭の中に像が立ち上がりません。
たとえばUberの箇所なら、先に対象を生成する必要があります。
Uber Engineeringは9月15日、「Large-Scale Automated Dependency Analysis at Uber」という記事を公開した。この記事では、数千規模のマイクロサービスが相互に呼び出し合うUberの環境で、「あるサービスに障害が起きたとき、どのサービスまで影響が波及するのか」を自動的に把握する仕組みを説明している。
マイクロサービスでは、サービスAがBを呼び、BがCを呼ぶ、といった間接依存が積み重なる。そのため、単純なサービス一覧だけでは障害影響を判断できない。Uberは実際の通信関係から依存グラフを継続的に構築し、直接依存だけでなく、その先の間接依存まで分析対象にしている。
この仕組みがAIOpsの観点で興味深いのは、LLMに障害原因を推測させる前に、「何が何に依存しているのか」という機械可読な構造を整備している点である。
これなら読者は、
「Uberの記事」
→「何の記事なのか」
→「どんな問題を扱うのか」
→「どう解いているのか」
→「なぜ今回取り上げるのか」
という順番でmental modelを組み立てられます。
またプロンプトが以下のように修正された。
【最重要：読者のmental modelを先に構築する】
読者はAWS、Datadog、Terraform、Claude Codeなど主要プロダクトの存在は知っている一方、その週に公開された個々の記事名、機能名、研究名、固有の概念、社内プロジェクト名については知らないものとして書いてください。書き手が調査済みであることを読者の既知知識と取り違えないでください。
新しい記事・機能・概念・固有名詞を初めて出す段落では、原則として次の順序で説明してください。
1. 誰が、いつ、何という記事・機能・発表を公開したか。
2. それが何を扱うものか。読者が頭の中に対象を作れるよう、1〜3文で素朴に説明する。
3. どのような問題を背景にしているか。必要なら既存方式や従来の前提を説明する。
4. その記事・発表の中心的な主張、仕組み、観測結果は何か。
5. その後で初めて『なぜ重要か』『SRE/Platform Engineeringにどう効くか』『AIOpsとどうつながるか』という評価・解釈を書く。
評価や含意から書き始めないでください。例えば『Datadogの9月15日の記事は重要である』ではなく、『Datadogは9月15日、○○という記事を公開した。この記事は△△を扱っている。そこで著者は□□と主張している。その上で、この発表が重要なのは…』のように、読者に対象を導入してから評価してください。
記事タイトルや固有名詞だけを主語にして説明を開始しないでください。『UberのLarge-Scale Automated Dependency Analysisは〜』のような書き出しは避け、まずその語が何であるかを導入してください。英語タイトルは必要に応じて原題を示してよいですが、日本語の説明を先に置き、原題は補助情報として扱ってください。
各段落を書く前に、『この段落の冒頭時点で読者は何を知っているか』『ここで初めて出す語は何か』『その語を理解するために不足している前提は何か』を内部的に確認してください。初出の対象を未定義のまま『この仕組み』『このアプローチ』『この問題』と指示語で受けないでください。指示語は、直前で対象が十分に説明されている場合だけ使ってください。
文章は『事実の提示 → 背景・構造の説明 → 仕組みや主張 → 含意・評価』の順に積み上げ、読者が順読みするだけでmental modelを再構成できるようにしてください。要約の圧縮率を上げるために前提説明を削りすぎないでください。短くする必要がある場合でも、固有名詞の導入と因果関係の中間過程は省略しないでください。
改善前と改善後の文章を比較すると以下となる。自分の感覚では修正後の方が読みやすい。
※注意：内容の技術的な正確性については未検証です。
改善前
Claude Code Projectsの9月17日の再設計では、複数エージェントの起動より、その後の調整を製品側が
担うようになった点が大きい。複数ターミナルやworktreeを使って人間が並列にタスクを進めること
は以前から可能だった。製品側は、タスクの対象範囲を決め、作業単位へ分け、各セッションへ委譲す
る。実行中の軌道修正、出力レビュー、最終統合まで同じ実行基盤が扱う。
。たとえば「checkoutのp75レイテンシを下げる」という目標を与えたとき、エ
ンドポイントごとのプロファイルや最適化を複数スレッドに分け、各スレッドで実験し、PRを生成し、
最終的な結果をまとめるという流れを製品側が組み立てる。
つまり、IDEに小規模な分散ジョブスケジューラとワークフローエンジンが組み込まれた。
改善後
Anthropicは9月17日、Claude Code向けの「Projectsの再設計 - フォルダーから会話へ」を公開した。ここ
でいうProjectsは、ひとつの開発目標に関係する複数のClaude Codeセッションをまとめて扱う機能で
ある。従来は人間が作業を分け、別々のセッションへ依頼し、その結果を最後に統合する必要があった。
新しいProjectsでは、利用者が「checkoutのp75レイテンシを下げる」といった目標を与えると、Claude
が対象範囲を整理し、エンドポイントごとの調査や最適化を複数のスレッドへ分けて実行する。各スレッ
ドは独立したクラウドセッションとして動き、途中で利用者が方向を修正できる。
ここから何が学べるのか？だけど、
- 適切に問題点を指摘することで、文章品質が改善できた。これは大きい。one-shotまたはfew-shotで良い文例、悪い文例ともう少し改善できるかも。
- この手の「解説文を書くときの定番の読みやすい言い回し」のようなものは一定パターンがあるので、そういうパターンをレゴブロックのように組み合わせて「型にはめる」アプローチの方が再現性高く読みやすい文章が作れるのかもしれない
- 文章の品質をllm-as-a-judgeするときの観点として、ここで指摘したような読書のmental modelを適切に構築できているか？はありなのかもしれない
あと、LLMが作った文中にある discourse-referent という概念は初見だが興味深い。ちょっと掘り下げて調べてみたくなった。
なんにせよ、LLMに一定品質の文章を作らせることができると毎週の情報収集がはかどるのでもう少し試行錯誤してみたい。
追記：
もう一つ別のテクニックをプロンプトに盛り込んでみた。これは『まったく新しいアカデミックライティングの教科書』で学んだTIPSだ。
これはこれでworkするのか暫く観察したい。
me
あと、細かいテクニックだけど
＞執筆者はDeepanshu Mehndiratta氏、Alok Srivastava氏、 Shivam Jindal氏である。
みたいな文章は
＞執筆者はUberでリードアーキテクトを務めるDeepanshu Mehndiratta氏、ソリューションアーキテクト
のAlok Srivastava氏、QAアナリストのShivam Jindal氏である。
などのようにセンテンスに付加情報を追加することで1つの文章の密度を上げてほしい。
AI
今回追加した観点は、「1文あたりの情報密度を高める」です。人物名だけで終わらせず、確認できる範囲で所属、役職、専門領域、担当範囲などを同じ文に自然に織り込むようにしました。
人物以外にも同じルールを適用します。たとえば単に「AgentCore」と書くのではなく、初出時には「AWSがBedrock上で提供するエージェント実行基盤AgentCore」のように、その対象の位置づけまで一文で分かる形にします。
一方で、情報密度を上げるために推測を混ぜないよう、「役職や所属は一次情報または信頼できる出典で確認できる場合だけ付加する」「一文には主張の核1つ＋補足1〜2個程度」という制約も入れています。
