見出し画像

第13回：AIで技術報告書の骨子を作る：結論・根拠・限界を先に分ける

研究開発者のAI実務ノート

技術報告書を書くとき、手が止まることがあります。

実験は終わっています。
データもあります。
グラフも作りました。
論文や特許もいくつか確認しました。
会議で話した内容もメモに残っています。

それでも、いざ報告書を書こうとすると、こうなります。

「結論から書くべきか、背景から書くべきか」
「どこまでを事実として書いてよいのか」
「考察が強すぎる気がする」
「次の実験方針まで書いてよいのか」
「上司が知りたいことと、自分が書きたいことがずれている気がする」
「若手の報告書を読んでも、何を判断すればよいのか見えにくい」

研究開発の報告書は、単なる文章作成ではありません。

実験結果や調査結果をもとに、次に何を判断するかを整理する仕事です。

そのため、文章をきれいにする前に、まず骨子を固めておきたいです。

ChatGPTやMicrosoft Copilotは、技術報告書の骨子を作る前段整理にも使えます。

ただし、AIに報告書を丸投げする話ではありません。

研究開発の技術報告書には、守秘情報、知財情報、特許化前のデータ、顧客案件が含まれることがあります。
そのため、AIで扱える情報と扱わない情報を分けたうえで、報告書の構成や論点整理を手伝ってもらいます。

1. 報告書を書く前に分けること

AIを使う前に、技術報告書の骨子として分けておきたいことがあります。

細かい文章の言い回しを整える前に、次のような点を整理します。

  • 誰に向けた報告書なのか

  • 何を判断してもらう報告書なのか

  • 結論は何か

  • 根拠となるデータや事実は何か

  • どこからが考察か

  • まだ言い切れないことは何か

  • リスクや不確実性は何か

  • 次の実験、調査、確認事項は何か

  • 知財部門や関係部署に相談したい点は何か

今回のポイントは、シンプルです。

AIには、技術報告書の完成文ではなく、報告書を書く前の設計図を作ってもらいます。

報告書は、文章量が多ければよいわけではありません。
読み手が判断しやすい順番で、事実、解釈、判断材料が並んでいることが大事です。

2. 研究開発者の困りごと

技術報告書で難しいのは、書くことそのものではありません。

むしろ、何を書くか、どの順番で書くか、どこまで書くかを決めることが難しいです。

たとえば、次のような報告場面があります。

  • 新しい材料の評価結果を報告する

  • 競合技術との比較結果をまとめる

  • 実験条件を変更した結果を説明する

  • 不具合原因の仮説を整理する

  • 論文調査、特許調査、実験結果をまとめる

  • 次の実験方針を上司に判断してもらう

  • 役員説明用資料の前段として、技術メモを作る

このとき、報告書に入れたい情報はたくさんあります。

背景。
目的。
実験方法。
評価条件。
結果。
グラフ。
考察。
未確認事項。
リスク。
次の実験案。
競合との差分。
知財の可能性。
量産化の課題。

どれも大事です。

ただ、全部を同じ重さで並べると、読み手は判断しにくくなります。

研究開発の報告書でよくあるのは、次のような状態です。

  • 結論が最後まで出てこない

  • 実験事実と考察が混ざっている

  • グラフは多いが、何を見ればよいか分かりにくい

  • 成功した点ばかりで、限界や未確認事項が薄い

  • 次の打ち手が曖昧

  • 判断してほしいことが書かれていない

  • 読み手が技術管理職なのか、担当者なのか、役員なのかが曖昧

書いている本人は分かっています。

しかし、読み手は同じ実験をしていません。
同じ背景を共有していないこともあります。
そのため、報告書では「何を判断するための資料か」を先にそろえておきたいです。

ここにAIを使う余地があります。

3. AIを使うと何が変わるか

AIを使うと、技術報告書を自動で完成させられるわけではありません。

実験条件の意味を理解しているのは担当者です。
データの妥当性を判断するのも人です。
社内事情、顧客事情、知財上の扱いを判断するのも人です。

ただ、AIは報告書を書く前の整理に使えます。

たとえば、次のような作業です。

  • 報告書の見出し案を作る

  • 結論、根拠、考察、未確認事項を分ける

  • 読み手別に説明順を変える

  • 比較表に入れる項目を出す

  • リスクや不確実性を洗い出す

  • 断定しすぎている表現を見直す

  • 追加で確認したい実験や調査を挙げる

  • 上司に判断してほしい論点を整理する

特に役に立つのは、「自分では当たり前だと思っている前提」を外に出す作業です。

報告書を書いていると、つい自分の頭の中では分かっている順番で書いてしまいます。

しかし、読み手が知りたい順番は少し違うことがあります。

担当者は、実験条件から説明したい。
管理職は、まず結論と判断事項を知りたい。
役員は、技術の細部より、事業判断への影響を見たい。
知財部門は、技術的特徴と公開前情報の扱いを確認したい。

AIに骨子を作ってもらうと、この読み手の違いを意識しやすくなります。

4. 今回使うツール

今回使う主なツールは、ChatGPTとMicrosoft Copilotです。

ChatGPT

ChatGPTは、報告書の骨子作り、論点整理、表現の見直し、リスク整理に使いやすいです。

たとえば、抽象化した実験メモや公開情報をもとに、次のような依頼ができます。

  • 報告書の構成案を作る

  • 読み手別に説明順を変える

  • 事実と考察を分ける

  • 不明点や追加確認事項を洗い出す

  • 強すぎる表現をやわらげる

  • 次の実験方針を複数案に整理する

ただし、未公開データや社内固有情報をそのまま入れるのは避けたいです。

Microsoft Copilot

Microsoft Copilotは、会社で導入されている場合、Word、PowerPoint、Teams、Outlookなどの業務文書と接続しやすい場面があります。

技術報告書そのものをWordでまとめる。
会議メモを整理する。
PowerPoint資料の前段として構成を作る。
上司への説明文を短くする。

こうした会社員業務との接点で使いやすいです。

ただし、会社契約であっても、入力してよい情報の範囲は社内ルールによります。
研究開発では、特許化前データや顧客案件を扱うことがあるため、利用前に社内のAI利用ルールを確認しておくと安心です。

5. 無料または会社支給ツールでできること

まずは、無料または会社支給の範囲でも十分に試せることがあります。

大事なのは、いきなり実データを入れないことです。

たとえば、次のような形なら始めやすいです。

  • 実験テーマを抽象化する

  • 測定値を入れずに、結果の傾向だけを書く

  • 材料名や製品名を一般名に置き換える

  • 顧客名や共同研究先名を入れない

  • 特許化前の発明内容を伏せる

  • 「報告書の構成だけ」を相談する

たとえば、実際のデータは入れずに、次のように相談します。

研究開発の技術報告書の骨子を作りたいです。

守秘・知財保護のため、会社名、製品名、材料名、配合、測定値、顧客名、共同研究先名、特許化前の発明内容は入力しません。

以下は抽象化した情報です。

技術分野：
〇〇系材料の性能改善

報告書の読者：
部門内の技術管理職

報告書の目的：
次の実験方針を判断してもらうこと

現在の状況：
複数の条件を比較し、性能と再現性に差が出ている

結果の傾向：
- 条件A：性能は高いが、ばらつきが大きい
- 条件B：性能は中程度だが、再現性が高い
- 条件C：性能は低いが、実用面で扱いやすい

依頼：
1. 技術報告書の見出し案を作成してください
2. 結論、根拠、考察、未確認事項を分けてください
3. 比較表に入れる項目案を出してください
4. 断定を避けたい表現を指摘してください
5. 追加で確認したい実験や調査を挙げてください

制約：
- 事実と推測を分ける
- 不明な点は「追加確認が必要」と書く
- 最終判断は人間が行う前提で整理する

このくらいなら、実データを渡さずに、報告書の骨子だけを相談できます。

AIに任せるのは、結論そのものではありません。
結論を説明するための並べ方です。

6. 上位プランや会社契約版を使うと深まること

上位プランや会社契約版のAIを使うと、長いメモ、複数の資料、会議メモ、過去報告書の構成などを扱いやすくなる場合があります。

ただし、ここでも大事なのは、使いやすさより先に情報管理です。

上位プランや会社契約版を使うと、次のような作業が深まります。

  • 長めの技術メモから報告書構成を作る

  • 複数の実験結果メモを同じ形式で整理する

  • Word文書の構成を見直す

  • PowerPoint化する前のストーリーを確認する

  • 報告書の読み手を変えて要約する

  • 若手の報告書をレビューする観点を作る

  • チーム共通の報告書テンプレートを作る

一方で、入力できる情報の範囲は、ツールの契約、会社の管理設定、社内ルールによって変わります。

「有料だから安心」と考えるより、
「どの環境で、どの情報まで扱ってよいか」を確認してから使う方が、研究開発では現実的です。

7. 実際の手順

ここからは、AIで技術報告書の骨子を作る手順を整理します。

手順1：まず読み手を決める

技術報告書を書く前に、まず読み手を決めます。

同じ実験結果でも、読み手によって構成は変わります。

  • 同じチームの研究者向け

  • グループマネージャー向け

  • 部門長向け

  • 役員向け

  • 知財部門向け

  • 品質保証部門向け

  • 事業部門向け

たとえば、同じ報告でも、研究者向けなら実験条件やデータの細部が重要になります。
管理職向けなら、判断事項、リスク、次の打ち手が重要になります。
役員向けなら、技術の意味、事業への影響、投資判断との関係が重要になります。

AIに依頼するときも、最初に読み手を書いておきたいです。

読者は、部門内の技術管理職です。
細かい測定条件よりも、次の実験方針を判断するための結論、根拠、リスクを重視します。

この一文があるだけで、AIの出力は変わります。

手順2：報告書の目的を決める

次に、報告書の目的を決めます。

技術報告書には、いくつかの目的があります。

  • 結果を共有する

  • 実験方針を判断してもらう

  • 技術課題を整理する

  • 顧客説明の準備をする

  • 特許出願の可能性を検討する

  • 量産化に向けた課題を整理する

  • 追加予算や設備利用の判断材料にする

目的が曖昧なまま書くと、報告書全体が散らかりやすいです。

AIに依頼するときは、次のように書きます。

この報告書の目的は、条件Aを継続評価するか、条件Bを基準条件として次の実験に進むかを判断してもらうことです。

目的が決まると、必要な情報と不要な情報を分けやすくなります。

手順3：手元メモを事実、考察、判断に分ける

技術報告書で混ざりやすいのが、事実、考察、判断です。

たとえば、次のような文章があります。

条件Aは最も性能が高く、次の候補として有望である。

これは一文に見えますが、実は複数の要素が入っています。

  • 事実：条件Aは測定値が高かった

  • 考察：性能向上に関係する要因があるかもしれない

  • 判断：次の候補として検討したい

この分解をしないまま報告書を書くと、読み手は「どこまで確認済みなのか」が分かりにくくなります。

AIには、次のように頼めます。

以下の技術メモを、事実、考察、判断、未確認事項に分けてください。

制約：
- 事実は、観察・測定・確認済み事項だけにしてください
- 考察は、事実から考えられる可能性として書いてください
- 判断は、報告者の提案として書いてください
- 根拠が足りないものは、未確認事項に入れてください

この整理をしてから書くと、報告書の信頼感が上がります。

手順4：結論を先に仮置きする

報告書を書き始める前に、結論を仮置きします。

ここでいう結論は、最終結論でなくても構いません。

たとえば、次のような仮置きです。

  • 条件Aは性能面で有望だが、再現性確認が必要

  • 条件Bは性能は中程度だが、次の基準条件に使いやすい

  • 条件Cは主候補ではないが、量産性の観点では参考になる

  • 現時点では、条件Aと条件Bを次段階で比較したい

この仮結論があると、報告書の構成が決めやすくなります。

AIには、次のように依頼できます。

以下の整理メモをもとに、技術報告書の冒頭に置く仮結論を3案作成してください。

条件：
- 断定しすぎない
- 確認済みの事実と、今後確認したいことを分ける
- 技術管理職が次の判断をしやすい表現にする
- 1案あたり3行以内にする

AIの結論案をそのまま使うのではなく、見比べながら「自分たちが本当に言えること」に戻していきます。

手順5：比較軸をそろえる

複数条件や複数技術を比較する報告書では、比較軸が大事です。

条件Aは性能を詳しく書いている。
条件Bは再現性だけ書いている。
条件Cは実用面だけ書いている。

このように、条件ごとに書いている観点が違うと、読み手は比較しにくくなります。

AIには、比較表の項目案を出してもらうと整理しやすくなります。

以下の3条件を比較する技術報告書を作ります。

条件A：
性能は高いが、ばらつきが大きい

条件B：
性能は中程度だが、再現性が高い

条件C：
性能は低いが、実用面で扱いやすい

依頼：
比較表に入れる項目案を作成してください。

観点：
- 性能
- 再現性
- 実験条件の扱いやすさ
- 追加確認が必要な点
- 実用化を考えたときの懸念
- 次の実験で確認したいこと

出力：
項目名と、その項目で何を確認するかを箇条書きで整理してください。

本文では実際の表を作らなくても、比較軸をそろえるだけで報告書は読みやすくなります。

手順6：リスクと未確認事項を分ける

技術報告書では、良い結果だけを書くと、かえって判断しにくくなることがあります。

研究開発では、うまくいった点と同じくらい、まだ分からない点が大事です。

  • 再現性は十分か

  • サンプル数は足りているか

  • 評価条件は妥当か

  • 測定誤差の可能性はあるか

  • 別ロットでも同じ傾向か

  • 長期安定性は確認したか

  • 量産条件で再現できるか

  • 特許や他社権利に関係しそうか

AIには、リスクを洗い出してもらうことができます。

以下の技術報告書メモについて、リスクと未確認事項を整理してください。

依頼：
1. 技術リスク
2. 実験設計上のリスク
3. 解釈上のリスク
4. 実用化を考えたときのリスク
5. 知財・特許面で相談したい可能性がある点

制約：
- 断定せず、「確認したい点」として書く
- 根拠が足りないものは、追加確認事項に入れる
- 知財判断は行わず、知財部門に相談する論点として整理する

ここで大事なのは、AIにリスクを断定させないことです。

リスク候補を出してもらい、人間が確認する。
この使い方が現実的です。

手順7：最後に文章化する

骨子ができてから、文章化に入ります。

この順番が大事です。

いきなりAIに「技術報告書を書いて」と頼むと、それらしい文章は出ます。
ただ、結論が曖昧だったり、根拠が薄かったり、実験データ以上のことを言ってしまうことがあります。

先に骨子を作り、次に文章化します。

以下の骨子をもとに、技術報告書の本文案を作成してください。

条件：
- 研究開発部門内の技術管理職向け
- 結論を冒頭に置く
- 事実、考察、未確認事項を混ぜない
- 断定しすぎない
- 今後の確認事項を最後に整理する
- 社内固有情報や未公開情報を補完しない
- 不明な点は不明と書く

AIの文章は、最後に必ず人が確認します。

技術的に正しいか。
データ以上の主張をしていないか。
守秘や知財上の問題がないか。
読み手に判断してほしいことが明確か。

この確認は、研究開発者の経験が活きる部分です。

8. プロンプト例

ここでは、技術報告書の骨子作りに使いやすいプロンプトをいくつか置いておきます。

プロンプト例1：報告書の骨子を作る

あなたは、研究開発業務を支援する担当者です。

目的：
技術報告書の骨子を作りたいです。

守秘・知財保護のため、会社名、製品名、材料名、配合、測定値、顧客名、共同研究先名、特許化前の発明内容は入力しません。

読者：
部門内の技術管理職

報告書の目的：
次の実験方針を判断してもらうこと

背景：
〇〇系技術について、複数条件の比較評価を行っています。

入力情報：
- 条件Aは性能が高い傾向がありますが、ばらつきがあります
- 条件Bは性能は中程度ですが、再現性があります
- 条件Cは性能は低いものの、扱いやすさがあります
- 現時点では、条件Aと条件Bを次の候補として比較したいです

依頼内容：
1. 技術報告書の見出し案を作成してください
2. 各見出しに書く内容を箇条書きで整理してください
3. 冒頭に置く結論案を3つ作成してください
4. 事実、考察、未確認事項を分けてください
5. 追加で確認したい実験や調査を挙げてください

制約条件：
- 事実と推測を分ける
- 不明な点は「追加確認が必要」と書く
- 判断を断定しない
- 社内固有情報を前提にしない
- 最終判断は人間が行う前提で整理する

プロンプト例2：若手の報告書をレビューする

以下は、研究開発テーマに関する技術報告書の下書きです。

依頼：
この下書きを、技術管理職がレビューする観点で確認してください。

確認観点：
- 結論が冒頭で分かるか
- 何を判断してほしい報告書か分かるか
- 実験事実と考察が分かれているか
- データ以上の断定がないか
- 比較条件がそろっているか
- リスクや未確認事項が書かれているか
- 次の実験方針が具体的か
- 知財部門に相談した方がよい可能性がある点はないか

出力形式：
1. 良い点
2. 分かりにくい点
3. 追加した方がよい観点
4. 断定を避けたい表現
5. 上司に確認した方がよい判断事項

制約：
- 技術的な結論を勝手に変えない
- 不明な点は不明と書く
- 守秘・知財上の注意点も指摘する

プロンプト例3：報告書を上司向けに短くする

以下の技術報告書メモを、上司向けに短く整理してください。

目的：
会議前に、判断事項を共有するためです。

出力：
1. 結論を3行
2. 根拠を3点
3. 未確認事項を3点
4. 判断してほしいことを1つ
5. 次のアクション案を3つ

制約：
- 断定しすぎない
- 事実と考察を分ける
- 技術的な細部を削りすぎない
- 社内固有情報を補完しない

プロンプト例4：知財部門に相談する前の論点整理

以下の技術報告書メモについて、知財部門に相談する前の論点を整理してください。

注意：
特許性、侵害、権利範囲の判断は行わないでください。
研究開発者が知財部門に相談しやすくするための論点整理だけを行ってください。

依頼：
1. 技術的に特徴になりそうな点
2. 公開前に注意したい情報
3. 特許出願前に社外共有を避けたい情報
4. 既存特許や公報を確認した方がよさそうな観点
5. 知財部門への相談メモ案

制約：
- 法的判断はしない
- 断定表現は避ける
- 「相談候補」「確認候補」として整理する

9. 失敗しやすいポイント

AIで技術報告書を作るとき、失敗しやすいポイントがあります。

失敗1：いきなり本文を書かせる

この内容で技術報告書を書いてください。

この頼み方でも文章は出ます。

ただ、報告書の目的や読み手が曖昧だと、一般的な文章になりやすいです。

まずは本文ではなく、骨子から作る方が進めやすいです。

失敗2：事実と考察が混ざる

AIは、文章を自然につなげるのが得意です。

一方で、技術報告書では、自然な文章よりも、事実と考察を分けることが大事です。

「確認されたこと」
「考えられること」
「まだ分からないこと」
「提案したいこと」

この4つを分けておくと、報告書の信頼感が上がります。

失敗3：断定が強くなる

AIの文章は、読みやすい一方で、少し断定的になることがあります。

たとえば、次のような表現です。

条件Aは最適である。
この結果から、〇〇が原因であると分かる。
本技術は実用化可能である。

研究開発では、ここまで言えるかを確認したいです。

必要に応じて、次のように直します。

条件Aは、今回の評価範囲では有望な候補と考えられる。
〇〇が影響している可能性があるが、追加確認が必要である。
実用化に向けては、再現性、量産条件、長期安定性の確認が必要である。

失敗4：読み手がずれる

担当者向け、管理職向け、役員向けでは、報告書の形が変わります。

担当者向けなら、実験条件や測定方法を詳しく書きます。
管理職向けなら、結論、根拠、次の判断事項を前に出します。
役員向けなら、技術の意味、事業への影響、投資判断との関係を整理します。

AIに依頼するときは、読み手を先に書きたいです。

失敗5：守秘情報を入れすぎる

技術報告書は、AIに相談したくなる情報ほど、社外に出しにくい情報を含みます。

材料名。
配合。
評価条件。
測定値。
顧客名。
共同研究先。
特許化前のアイデア。
不具合原因の仮説。

こうした情報を、外部AIにそのまま入力するのは避けたいです。

AIには、実データではなく、抽象化した構成や観点を相談する。
この線を守るだけでも、使いやすくなります。

10. 守秘・知財・社内利用上の注意

技術報告書でAIを使うときは、守秘と知財の扱いを最初に確認しておきたいです。

特に注意したいのは、次の情報です。

  • 未公開の実験データ

  • 材料名、配合、製法、処理条件

  • サンプル名、製品名、開発コード

  • 顧客名、共同研究先名、仕入先名

  • 特許出願前の発明内容

  • 競合比較の詳細

  • 不具合原因に関する社内仮説

  • 社内会議の議事録

  • 役員説明用の未公開資料

これらは、会社の資産です。

AIに相談する場合は、次のように加工してから使いたいです。

  • 固有名詞を一般名に置き換える

  • 測定値を入れず、傾向だけにする

  • 条件名をA、B、Cに置き換える

  • 顧客名や製品名を削除する

  • 特許化前の発明内容を入れない

  • 公開済み情報と社内情報を分ける

  • 会社で許可されたAI環境を使う

また、会社支給のCopilotなどを使う場合でも、社内ルールを確認しておくと安心です。

会社契約だからといって、すべての情報を入力できるとは限りません。
研究開発、知財、顧客案件では、部門ごとのルールがあることもあります。

技術報告書でAIを使うときは、最初にこう決めておくと進めやすいです。

AIには、報告書の構成、見出し、比較軸、リスク整理を相談する。
未公開の実験データ、材料名、配合、顧客名、特許化前の発明内容は入力しない。
最終的な技術判断、知財判断、社外共有判断は人間と関係部署で確認する。

このくらい線を引いておくと、AIを怖がりすぎず、かといって過信しすぎずに使えます。

11. マネージャー視点で見ると

マネージャー視点で見ると、技術報告書の骨子作りは、個人の文章力だけの問題ではありません。

チームの判断品質に関わります。

若手の報告書を読むと、内容は頑張っているのに、判断しにくいことがあります。

実験は丁寧にやっています。
データも取っています。
グラフも作っています。
でも、何を判断してほしいのかが見えにくい。

これは、本人の能力が低いという話ではありません。
報告書を書く前の型が共有されていないだけかもしれません。

チームでAIを使うなら、次のような共通型を作ると使いやすいです。

  • 報告書の目的

  • 読み手

  • 結論

  • 根拠

  • 比較条件

  • 未確認事項

  • リスク

  • 次の打ち手

  • 判断してほしいこと

  • 知財・守秘上の注意

この型をチームで共有しておくと、報告書の粒度がそろいやすくなります。

AIは、若手の報告書を勝手に直すための道具ではありません。
むしろ、レビュー観点をそろえるための道具として使えます。

たとえば、マネージャーは次のようなプロンプトをチーム共通で用意できます。

この技術報告書の下書きを、次の観点でセルフレビューしてください。

1. 結論は冒頭にあるか
2. 何を判断してほしいかが明確か
3. 事実と考察が分かれているか
4. データ以上の断定がないか
5. 未確認事項が書かれているか
6. 次のアクションが具体的か
7. 守秘・知財上、入力や共有に注意すべき情報がないか

このようにしておくと、マネージャーが毎回同じ指摘をする負担も少し軽くなります。

「結論が見えない」
「根拠と考察を分けよう」
「次の打ち手を書こう」
「これは知財部門に相談した方がよさそう」

こうしたレビュー観点を、チームの共通言語にしていけます。

40代・50代の研究開発者の経験は、ここで活きます。

AIが作った骨子を見て、
「この結論は少し強い」
「このリスクが抜けている」
「この比較軸では判断できない」
「この表現は知財的に慎重にしたい」
と確認できるからです。

AIを使うほど、人間の確認力が大事になります。

12. まとめ

技術報告書は、文章を書く作業であると同時に、研究開発の判断材料を整理する作業です。

だからこそ、AIにいきなり完成文を書かせるより、まず骨子を作るところから使いたいです。

今回のポイントを整理します。

  • 技術報告書では、文章化の前に骨子を固める

  • 読み手と報告書の目的を先に決める

  • 結論、根拠、考察、未確認事項を分ける

  • 比較軸をそろえて、読み手が判断しやすくする

  • リスクや不確実性を隠さず整理する

  • AIの出力は、断定が強すぎないか確認する

  • 守秘、知財、特許化前データは入力しない

  • 最終判断は、研究開発者と関係部署で行う

AIは、技術報告書の中身を代わりに判断する存在ではありません。

ただ、報告書を書く前に、頭の中にある情報を並べ直す相手にはなります。

実験結果。
論文調査。
特許調査。
会議メモ。
上司の関心事。
次に判断したいこと。

これらを一度、AIと一緒に整理してから書き始める。

それだけでも、報告書を書く負担は少し軽くなります。

そして、読み手にとっても、判断しやすい報告書に近づきます。

まずは、未公開データを入れずに、抽象化したメモで「報告書の見出し案」だけ作ってみる。
そのくらいの小さな使い方から始めるのが、研究開発では現実的です。

これまでの記事

この連載を初めて読む方は、こちらも参考になります。

次回予告

次回は、役員・上司向けの1枚資料をAIと作る方法です。

技術報告書で整理した結論、根拠、限界を、短時間で判断してもらう資料にどう落とし込むかを考えます。

いいなと思ったら応援しよう！