公開B2B資料の読解

公開B2B資料のページ別読解と、架空会計事務所向け6枚の監査
2026-09-29／検証用。資料の文章・図版・実績を複写していない。

結論
前の6枚は差し戻し。2枚目の「最初の対象は、顧問先への確認メール」は、営業担当の説明をそのまま大見出しにした言葉であり、資料を探す・判断するための見出しになっていない。さらに、ページのほぼ全てが見出しと短文だけで、画面・業務フロー・条件の表・検証根拠を欠く。見出しを「対象業務：確認メール」に置換するだけでも不十分。サービス全体を最初に示し、具体例はその一部として扱い、各ページに実際の判断材料を置く必要がある。

資料とアクセス範囲
S. SmartHR公式 Service Overview、英語版8ページ
   https://smarthr.co.jp/assets/pdf/ServiceOverview_smartHR.pdf
   全8ページの本文と画面を確認。日本語の「SmartHRのご紹介」は公式資料一覧にあるが、全編の取得はフォーム経由であり、今回は確認できていない。英語版を日本語の営業文体の正解にしない。
K. サイボウズ公式 kintone 製品紹介、15 PDFページ
   https://kintone.cybozu.co.jp/material/pdf/kintone.pdf
   全15ページの文字抽出と画面を確認。見開き構成のページがある。
K2. サイボウズ公式 kintone 活用イメージ集 Vol.2、46ページ
   https://kintone.cybozu.co.jp/material/pdf/kintone_gyousyubetukatuyou_image_v2.pdf
   業種別事例集として参照。製品紹介資料や個社提案書とは用途が違う。
R. ラクス公式「楽楽電子保存」ご紹介資料、51 PDFページ
   https://www.rakus.co.jp/rakurakucloud/denshihozon/pdf/proposal_document.pdf
   PDF本文を全ページ抽出。表紙・全体像・利用イメージ・料金・サポート・連携・セキュリティの代表ページを画面確認。Web表示のページ数は50と出る場合があるが、取得したPDFは51ページだった。以下は取得PDFのページ番号。

SmartHR：全8ページの役割
S1　表紙。サービス名とPC・スマホの実画面。文章より、何の製品かを先に認識させる。
S2　全体像。従業員情報を集め、蓄え、利用する三段階に機能を配置。機能の地図。
S3　入社手続きと雇用契約。業務名、短い説明、従業員・人事の画面を組み合わせる。
S4　通知と承認の流れ。担当者の行為、申請と承認の関係、画面例。
S5　給与明細と年末調整。職員が使う画面とペーパーレス化する作業。
S6　従業員データベースと名簿。情報の蓄積・表示の画面。
S7　分析とサーベイ。グラフ画面と質問・集計の画面。
S8　ロゴだけの終端ページ。前回の分析で「問い合わせ導線」と推測したのは誤り。画面で訂正した。

SmartHRから採る点：表紙の実画面、最初の全体図、機能名をそのまま使う明瞭な見出し、画面と短い本文の分担。採らない点：8ページという長さ、日本語の語調、個社向け提案に必要な料金や導入条件があるという推測。

kintone製品紹介：全15 PDFページの役割
K1　表紙。サービス名、何をつくり何に使うかの短い説明、製品画面と人物。
K2　導入規模などの根拠、適用範囲、目次。ここにある数値はkintone自身の実績。
K3　製品の特長。アプリ作成、情報共有、拡張、AIなどを画面や図で分ける。
K4　アプリの作り方。複数の作成方法を実画面で比較する。
K5　業務課題と用途の対応。具体的な課題から利用先を探せる地図。
K6　用途別の例。管理・申請などを実画面付きで示す。
K7　部署別の例。読み手が自分の部門を選べるよう、業務と画面を並べる。
K8　具体的な機能。データ、履歴、通知、コメントなどを画面で示す。
K9　連携と拡張。何につながるか、条件・別契約も添える。
K10　帳票、会計、電子契約など、実務単位の連携例。
K11　AIを含む機能の使用例。プロダクト画面・操作対象・結果がある。
K12　セキュリティ。認証、権限、運用の要素を分ける。
K13　利用開始までのステップ。検討から実行へ進む順と準備。
K14　相談・サポートの窓口。利用前・利用中の支援を区分。
K15　料金表と動作環境。決裁時に必要な条件を一覧にする。

kintoneから採る点：製品の全体像→作り方→部門別/用途別→連携・AI→導入・価格という順。見出しは主としてページを検索できる名詞句で、画面内には具体的な用語と図がある。採らない点：製品機能、導入社数、画面、料金、AI機能をAI相談所自身のものとして扱うこと。図版の見た目も複写しない。

kintone活用イメージ集の構造
K2-1　表紙。
K2-2～3　業種・用途から選べる目次。
K2-4～41　原則として1事例を2ページ。最初のページで企業の業務、以前の困りごと、仕組み、変化を示し、次のページで利用条件や画面例を示す。事例ごとに見出しの文型は異なるが、業務と変化が具体的。
K2-43以降　パートナー情報等。個社提案の本文へそのまま移す部分ではない。
この資料は「実績のある事例集」であり、架空会計事務所への提案に同じ結果や導入効果を書ける根拠ではない。学ぶのは、業務→以前の作業→新しい仕組み→変化→画面・条件の対応づけ。

ラクス：全51 PDFページの役割
R01　表紙。製品名、資料名、会社名と連絡先。
R02　目次。会社、製品、法令背景、メリット、料金、支援、オプション等の章を提示。
R03　提供企業の概要と実績。検証可能な自社データを使って信頼を置く。
R04　製品群の地図。帳票保存がバックオフィス全体のどこかを示す。
R05　製品概要。扱う帳票、主な自動化、導入実績を整理。
R06　利用イメージ。入力経路と保存後の画面を同じページで示す。
R07　アップロード方法。経路の違いを実務手順に結び付ける。
R08　法令背景の章扉。
R09　対象となる電子取引と書類。制度の説明を製品と切り分ける。
R10　保存要件の整理。要件と対応を表で示す。
R11　対応不足のリスク。根拠を伴う説明。
R12　現在の運用を点検する問い。読み手に確認すべきことを具体化。
R13　製品の特長とメリットの章扉。
R14　選ばれる理由。自動読み取りなどの根拠を3つの要素に分ける。
R15　主な機能。機能別の短文・アイコン・条件の一覧。
R16　利用者にとっての変化。手入力や検索などの作業に結ぶ。
R17　管理者にとっての変化。属人化・運用管理など別の判断軸。
R18　連携機能の章扉。
R19　請求書収集にまつわる現状の手間。業務場面を示す。
R20　導入前後の業務フロー比較。自動収集へ変わる箇所を図示。
R21　導入設定の段取り。連携できるまでの具体的な操作。
R22　料金・サポートの章扉。
R23　料金表。月間件数による価格と対象範囲。
R24　サポートプランの比較表。含まれる対応と時間など。
R25　支援開始後の時間軸。導入時と運用時の違い。
R26　サポート内容が適合する場面。読み手の状況と支援をつなぐ。
R27　オプション一覧と価格・条件。
R28　アクセス制限の設定例。
R29　保存期間のオプションが必要になる場面。
R30　同オプションの料金表。
R31　証憑取得AIの用途とできること。具体的な作業単位で示す。
R32　同AIの導入前後フロー。
R33　同AIの費用と条件。
R34　API連携で使える処理。
R35　データセンター、暗号化、バックアップ等の安全性。
R36　対象書類と制限の比較。
R37　同社の関連製品との機能差。どの製品を選ぶかの判断表。
R38　関連製品の章扉。
R39　同社クラウド製品群の対応業務。
R40　勤怠、請求書等の製品群の続き。
R41　ID管理と人事労務等の製品群の続き。
R42　経費精算製品の概要と作業フロー。
R43　経費精算と帳票保存の連携。
R44　請求書発行製品の概要と入力・発行の流れ。
R45　債権管理製品の概要と入金消込の流れ。
R46　販売管理製品の概要とデータ連携。
R47　請求書受領製品の概要と処理フロー。
R48　勤怠管理製品の概要と集計。
R49　給与明細発行製品の概要。
R50　人事労務製品の概要。
R51　従業員ID管理製品の概要。

ラクスから採る点：比較・料金・支援内容は一枚ずつ表にし、機能説明は利用イメージの後に置き、オプションは本文から分ける。製品紹介に51ページ必要という意味ではない。連携・価格・実績はラクス固有の情報で、今回のAI相談所には転用できない。また、この資料にも標語調の見出しはある。語調だけで採用せず、直下に検証可能な図・条件・実績があるかを見る。

資料を比べて分かる見出しの型
1. 製品名・機能名・章名：製品の全体像、入力方法、利用イメージ、料金プランなど。本文を探せるラベルにする。
2. 相手の業務名：用途別・部署別・業種別の例。読み手が自社と照合できる。
3. 根拠を持つ成果：導入社数、実測された変化、具体的な導入前後。数値の出所と条件が近くにある。
4. 検討の条件：料金、サポート、セキュリティ、開始までのステップ。意思決定に使う表や図を伴う。
宣伝文句や文の見出し自体は禁止しない。ただし、1枚ごとに同じ決め台詞で進めたり、見出しを説明者のセリフにしたりしない。名詞句でも「導入判断の材料」のように中身が見えなければ弱い。

AIスロップとして現れた問題
・6枚中複数の見出しが「最初の対象は」「〜まで」「〜なら」「まず〜する」と話を進めるセリフになった。読者が後から必要な情報を探すためのラベルではない。
・文章は短いが、判断の根拠となる画面・実例・表を欠く。短さと大きな余白を「見やすさ」と誤判定した。
・「月26時間40分」のような仮定の数字を、大きな見出しと数字で実績らしく見せた。脚注の小さな留保では画面上の印象を打ち消せない。
・「まず一つの業務で使える形にする」は意味がありそうで、成果物・支援範囲・買い手の便益が読めない。曖昧な宣伝語を具体的な情報に置き換える必要がある。
・この問題は「AIが書いたか」を判定しているのではない。文面と画面が、配布用B2B資料として情報を渡しているかの判定である。

前の6枚の具体的な失敗
1　表紙：形式は整っているが、AI相談所の支援全体ではなく確認メール1用途に資料全体を狭めている。サービスの位置づけが見えない。
2　「最初の対象は、顧問先への確認メール」：会話の途中のような大見出し。現状と導入後を二つの短文で置いたが、業務量・作業の流れ・画面の証拠がない。余白が情報設計ではなく情報不足になっている。
3　資料メモとメール案の二列：実演ではなく、文字の例。実際に何を入力し、AIがどの部分を抽出し、どんな成果物として残るかを示していない。
4　架空の200件×8分を大きく表示：現地の業務量も実測時間もないのに、数値が資料の主役になっている。脚注が小さく、実績のように見える。
5　支援内容と価格：何を・誰が・いつ・どの形式で進めるかが薄い。月額が唐突に現れる。外部提示未承認の事業計画初稿を閲覧ページに載せた点も問題。
6　導入判断の材料：数字を求めるだけで、相手が判断するための資料になっていない。相談導線も小さな脚注に埋まる。

作り直す場合の見出し例（採用確定ではない）
表紙：架空会計事務所様向け／AI業務改善・定着支援のご提案
全体像：ご提案の概要
例の入口：活用例｜月次資料の確認連絡
実演：入力資料と確認メール案
作業の変化：確認連絡の作成手順（現状とAI利用時）
費用：支援内容・料金・契約条件
ここで「活用例」と呼ぶのは、確認メールだけが商材だと誤認させないため。後続の画面で、案件情報の整理・確認事項の抽出・報告文・顧客対応文という支援可能な範囲の初稿との関係を示す。効果の数値は相手の実数が得られるまで置かない。実画面・成果物のサンプルは架空であることを明示する。

スキルに入れるべき検査
A. 参考資料を開いたことと、その用途を記録する。ページ番号、見出し型、本文密度、図・画面、全体順を簡潔に保存し、資料種別の違いを残す。
B. 原稿前に「資料全体の商材」と「その中の一例」を分ける。一例を冒頭に置く場合も、資料全体をその用途に狭めない。
C. 見出しのみを通読して、会話のつなぎ文・毎ページの決め台詞・曖昧な章名・根拠のない数値訴求を検出する。名詞句へ機械的に揃えない。
D. ページごとに、本文ではなく実際に載る図・画面・表・実例・比較条件を指定する。文章量が少ないだけでは見やすさと判定しない。
E. 資料が販促・商談・社内稟議・製品概要・事例集のどれかを明記する。参考企業の資料種別が違うなら、丸写しの順序を避ける。
F. 架空効果と確定費用を近接して対比し、実績に見せない。価格・実績・支援範囲に未承認条件があれば、外部閲覧ページに出す前にも点検する。
G. PPTXを実際に描画し、見出しだけ・図だけ・本文だけの読みをそれぞれ検査する。6枚目から1枚目まで逆に見ると、薄いページを発見しやすい。

内部の文字抽出データ
公式PDFの全ページ抽出テキストは work/b2b_source_review_2026-09-29/ に内部検証用として保存した。kintoneとラクスは抽出できた。SmartHR英語版はPDF内部の文字コードが崩れるため、画像と公式Webのテキストで照合した。抽出結果をそのまま良い日本語の例として使わない。著作権がある資料の本文全文をユーザー向け成果物として再配布しない。

Devinに同じ根拠を渡した結果と、人による採否
Devin SWE-2 Maxの独立した会話A・Bへ、上記の資料の内部抽出テキスト、SmartHRの視覚読解、共通の制作条件、当時のスライド候補v0.7、Stop AI Slop候補を渡した。Aは旧6枚も見せて査読させ、Bには旧6枚を見せずに新規作成させた。原文がBに流れない条件を守った。両者の生回答と実行記録は内部の work/b2b_source_review_2026-09-29/devin_A と devin_B に保存した。

Aの旧稿診断は有効だった。2枚目のセリフ調見出し、図や成果物のない「文章＋余白」、架空の26時間40分を大きく見せる構図、表紙が支援全体ではなく確認メールだけを売るように見える問題を挙げた。一方、Aの新構成案にも、確認されていない導入ステップや20枚に広げるための細分化がある。Aの案を完成見本にはしない。

Bは資料種別の違いと、実画面・料金表・支援条件の役割を読み取った。しかし初稿の2枚目に「貴所の業務を一緒に整理し」を入れ、確認されていない「AIツール選定の相談」「1回目・2回目の詳細工程」「翌月に次業務へ進む」も足した。公開資料を大量に読ませても、曖昧な営業文と事実の追加は残る。よってBの初稿も不採用とし、同じ会話に具体的な差し戻しを送った。モデルが二つとも賛成した項目も本人承認とは扱わない。

再設計の仮画面は6枚。旧稿との違いは、1枚目をサービス全体の名前に戻し、2枚目で初動の業務例と提供方法を表に分け、3枚目で架空資料メモ→確認事項の候補→メール下書きを実際の形で見せ、4枚目で他の初動候補、5枚目で未承認と明示した条件表、6枚目で返信の行動を示したこと。業務量や時短効果は実測されていないので、架空の削減時間を主役にするページを削った。スマホ幅390pxとPC幅1280pxで全6ページの横はみ出しなしを確認した。これは内部検証用の仮画面で、相手の反応や営業成果は未検証。

Bへの差し戻し後の結果
同じDevin会話の再回答は正常終了した。B自身が「一緒に整理」、未確認のツール選定、面談1回目・2回目の工程、翌月の進行、人の修正工程を初稿から除いた。20枚へ無理に広げるのをやめ、現状の情報で作れるのは約10枚とし、実画面、実績、定着支援の詳しい内容、申込導線が揃えば追加できるページを別に示した。この判断は採る。一方で、再回答の見出しとCTAは実務上の無難さが中心で、買い手に何を期待させるかの表現はなお検討余地がある。Bの6枚をそのまま完成稿にせず、上記の仮画面は人が内容を選び直して制作した。