前任者が残した作業報告書の内容から、
質問した作業の手順を回答する

金曜の夕方。突然の異動内示。

担当していたサーバー管理業務を、来週月曜には別の人間へ渡さなければならない。

「報告書は残してある。でも、あいつに全部説明する時間はない」——

そう思いながら退勤した翌週の月曜日。引き継いだ担当者から、最初の連絡が来る。

「SSL証明書のエラーが出てるんですが、どのファイルをどこに置けばいいか、報告書だけじゃよくわからなくて……」

これは、どこの会社でも起きている光景だ。

問題は、担当者のスキルでも、報告書の質でもない。

**報告書は”保存”されているが、”答えてくれない”**のだ。

PDFを開いて、ページをめくって、該当箇所を探して、読んで、解釈して——その作業だけで30分が飛ぶ。そして「この手順の前後に何かあったかな」という疑問は、もう前任者に聞くしかない。でも前任者はいない。

あるIT部門のリーダーが、KnowledgeLMの「引き継ぎQ&Aエージェント」を試したのは、まさにこんな状況に追い詰められたときだった。

「正直、AIに期待していなかった。でも、報告書をそのままアップロードして、エージェントに役割を持たせてみたら——」

彼はそのときの画面を、今でも鮮明に覚えている。

▶️ 実際の会話シーン

これは、実際にKnowledgeLMの引き継ぎQ&Aエージェントが返した回答だ。

ユーザー： SSL証明書が期限切れした

エージェント（引き継ぎQ&A）：

📋 作業概要

SSL証明書が期限切れ（またはエラー）になった際の対応手順です。 証明書ファイルをサーバーへ配置し、Apacheを再起動することで問題を解消します。

参照報告書：

• 202605-2作業-MDD_SSL証明書エラー問題解決作業.pdf（優先）
• 202605作業-MDD_SSL証明書更新作業.pdf（補足参照）

🔢 作業手順

ステップ 1：証明書ファイルをサーバーへアップロードする

SSL証明書と中間認証局証明書の2ファイルをサーバーへ転送します。

$ scp * www@****.****.****.****:~/

⚠️ ホスト名・ユーザー名はセキュリティのためマスキングしています。実際の接続先は報告書原本を確認してください。

ステップ 2：証明書ファイルを所定のディレクトリへ移動する

$ sudo mv ****.engg.example.co.jp.cer /etc/pki/

⚠️ 完全なパスは報告書原本でご確認ください（不明点に記載）。

ステップ 3：Apacheサービスを再起動する

$ sudo systemctl restart httpd.service

⚠️ 再起動中はWebサービスが一時停止します。事前に関係者へ連絡することを推奨します。

ステップ 4：証明書の検証確認を行う

$ openssl s_client -connect ****.engg.example.co.jp:443 -showcerts

期待する結果： Verify エラーが表示されないこと。

⚠️ 注意事項

• 更新後のSSL証明書の有効期限は 2026年11月15日 13時28分 です。

❓ 不明点・確認が必要な箇所

1. ステップ2の移動先パスが不完全。原本 202605-2作業-MDD_SSL証明書エラー問題解決作業.pdf を直接確認してください。
2. 中間認証局証明書の移動手順について、完全な手順が原本で確認が必要な箇所があります。
3. 移動先ディレクトリの完全パスや中間証明書の結合手順が欠落しているため、報告書の補完・改訂を推奨します。

SOURCES: 202605-2作業-MDD_SSL証明書エラー問題解決作業.pdf, 202605作業-MDD_SSL証明書更新作業.pdf

これを見て、あなたは何を感じたか。

手順が出てきただけではない。根拠となった報告書の名前が示され、不明な点は「不明だ」と正直に教え、さらに報告書の改訂まで提案している。

これは、優秀な前任者が隣の席にいるのと、変わらない体験だ。

「データの性質と意図を提案」という機能のことだ。

KnowledgeLMに資料をアップロードするとき、あなたはその資料が”どんな性格を持つ情報か”を指定できる。

たとえば——

• 「手順・マニュアル」：ステップバイステップの実行指示。順序を崩さず説明せよ
• 「公式規定」：これは絶対的なルールであり、例外は認められない。回答の主軸にせよ
• 「アーカイブ」：過去の経緯を確認するための資料。現状の回答には直接反映させるな

でも正直に言う。「この報告書はどれに当たるんだろう」と迷うことは、あるはずだ。

だからKnowledgeLMは、AIがデータを分析して性質と意図を提案してくれる。

ファイルをアップロードして「データの性質と意図を提案」ボタンを押すだけ。AIが内容を読み取り、「これは手順・マニュアルとして扱い、ステップバイステップで説明するのが適切です」と教えてくれる。

銀行の金庫を想像してほしい。現金を入れるとき、「これは普通預金か、定期か」を明示することで、引き出し方のルールが変わる。KnowledgeLMの「データの性質と意図」は、まさにその”ラベル”だ。正しいラベルをAIが提案してくれるから、専門知識がなくても精度の高い回答を引き出せる。

Before（このエージェントがない世界）

• 引き継ぎのたびに、前任者への連絡が発生する
• 報告書を読み解くのに30分〜1時間かかる
• 「ここに書いてあるけど、これで合ってますか？」という確認が止まらない
• 報告書に欠落があると、作業が止まる

After（このエージェントがいる世界）

• 自然な言葉で質問するだけで、根拠付きの手順が出てくる
• 不明点は「不明です」と正直に教えてくれる
• 報告書の改善提案まで自動でしてくれる
• 前任者が物理的にいなくても、業務は動き続ける

▶️ AIエージェント作成シーン

専門知識への「データの性質と意図を提案」機能

• AIエージェントにアップロードしたデータを生成AIが自動分析し、「データの性質ラベル」と「データを与える意図」の最適な組み合わせを提案する
• 性質ラベルは「手順・マニュアル」「公式規定」「FAQ」など12種類から選択。意図は「ステップバイステップで説明せよ」「絶対的なルールとして扱え」など12種類から指定できる
• 専門知識のない担当者でも、AIの提案に従うだけで回答精度の高いエージェントを構築できる

📊 情シス責任者の視点

誰がどの報告書をエージェントに読み込ませたか、どのモデルを使っているか——KnowledgeLMの管理画面では、それがすべて見える。データの性質ラベルで「社内限定」を指定すれば、回答のトーンを内部向けに調整するよう生成AIに指示できる。情報統制と活用の両立が、設計レベルで組み込まれている。

🏃 営業・現場リーダーの視点

エンジニアに頼まなくていい。報告書をアップロードして、「性質と意図を提案」ボタンを押すだけ。5分後には、チーム全員が使える引き継ぎエージェントが完成している。新メンバーが「あの件、どうすればいい？」と聞いた瞬間、正確な手順が返ってくる。問い合わせが減り、現場の手が止まらなくなる。

🚀 DX推進メンバーの視点

「AIを入れたのに誰も使わない」——その本当の原因は、現場にとって”使いにくい”からだ。引き継ぎQ&Aエージェントは、特別なプロンプト知識なく、自然な質問で答えが出る。全社展開のハードルが下がり、属人化解消という成果を経営に示せる。乗り遅れる前に、まず一つのチームから始められる。

報告書は、保存されていても”答えてくれない”。

その現実を変えるのが、KnowledgeLMの引き継ぎQ&Aエージェントだ。

データの性質と意図をAIが提案し、正確な根拠と不明点を正直に示し、次の担当者が迷わず動ける——それが、ただの”文書管理ツール”との決定的な違いだ。

統制が強いほど、活用も広がる。現場は止まらない。

KnowledgeLMは、その両方を同時に実現するために設計されている。