教材
AIは構造を読んでいる
生成AIに長い指示を出すとき、すべてを1つの段落に詰め込むと精度が落ちます。 前提・依頼・制約・出力形式が混ざり、どれが指示でどれが背景なのか区別できないためです。
見出しで役割を分けると、そのまま読み分けてくれます。
## 前提
当社は未経験からのIT転職を支援するメディアを運営している。
## 依頼
求人紹介メールの件名を5案作ってほしい。
## 制約
- 全角30文字以内
- 誇張した表現を使わない
## 出力形式
番号付きリストで、案ごとに狙いを一行添える
出力形式を明示するだけで、手直しの量がはっきり減ります。
議事録は「決まったこと」と「宿題」を分ける
議事録が読まれないのは、発言の記録と決定事項が同じ流れで並んでいるからです。
## 決まったこと
- 公開は10月1日
- 価格は据え置き
## 持ち帰り
- [ ] 山田: 見積もりを再取得(9/20まで)
- [ ] 佐藤: 法務確認
担当と期限をタスクリストにしておくと、次の会議でそのまま進捗確認に使えます。
まとめ
この講座で扱った記号は10個ほどです。覚えることは多くありませんが、効く場面は議事録・仕様書・バグ報告・AIへの指示・READMEと、日常業務のほぼ全域にわたります。
まずは次に書く文書で、見出しと箇条書きだけを使ってみてください。それだけで読み手の負担ははっきり変わります。
このレクチャーで学ぶこと
- 構造化するとAIの精度が上がる
- 議事録は決定と宿題を分ける
- 今日から使える型
質問
まだ質問は投稿されていません。
質問投稿
ログイン後に質問の投稿ができます。
#1
未完了
Markdownとは ― 記号で構造を伝える
#2
未完了
見出しと段落 ― 文書に骨格を与える
#3
未完了
リストと強調 ― 箇条書きで読み手を助ける
#4
未完了
リンクと画像 ― 情報の置き場所をつなぐ
#5
未完了
コードブロックと引用 ― 記号をそのまま見せる
#6
未完了
表 ― 比較を一目で伝える
#7
未完了
GitHub Flavored Markdown ― 現場で使う拡張記法
#8
未完了
README.md を書く ― 最初に読まれる文書
#9
未完了
Issue と Pull Request を書く ― 伝わる報告の型
#10
未完了