はじめに
資料の確認、執筆、点検。それぞれをAIに頼めるようになっても、仕事全体が自動的につながるわけではありません。調査で確認できなかったことが、執筆の段階では確定情報として扱われていたら、担当を分けた意味が薄れてしまいます。
最終回は、一つひとつの作業の間に目を向けます。誰から何を受け取り、何を渡し、問題があればどこへ戻すのか。その関係を見える形にします。
ここでいうグラフは、仕事の関係図
2026年8月にarXivで公開されたグラフエンジニアリングの総説論文は、タスク、エージェント、システムの状態を明示的なグラフ構造として扱う考え方を提唱し、関連研究を整理しています。公開ページからは査読の状況を確認できないため、ここでは新しい議論の一つとして紹介します。あらゆる仕事で従来の方法より優れると確立した手法として紹介するものではありません。arXiv「Graph Engineering in the Era of LLM Agents」
この論文は、プロンプト、コンテキスト、ハーネス、ループ、グラフという発展の系譜を描いています。本連載では、その整理をそのまま技術の優劣とせず、仕事の準備を見直すために併用する四つの観点として扱います。
この記事では、そこから「作業と担当、進み具合の関係を設計する」という発想を、人とAIの記事制作に応用します。棒グラフの作成や、情報の関係を蓄える知識グラフそのものを説明する回ではありません。
LangGraphの公式資料にも、分岐や並行処理、評価と修正を含むワークフローの実装例があります。ただ、今回の整理にはその導入は必要ありません。紙の図や表でも始められます。LangGraph公式資料「Workflows and agents」
先に決めるのは、担当の人数ではない
引き続き、架空の「まちのWeb相談室」の記事を考えます。仕様は、小規模事業者向けのWeb制作、相談後の個別見積もり、公開後の更新は別契約です。実在サービスの条件を示すものではありません。
必要なのは、まず確定した事実をそろえ、それを使って書き、できた文章を確かめることです。同じAIを順に使っても、人とAIで分担しても構いません。担当を増やすこと自体は目的にしません。
今回の作業図は、次のようになります。
- 資料を確認し、確定事項と未確認事項を分ける。必須の情報が足りなければ、資料の管理者へ確認して保留する。
- 確定事項を使って下書きを作る。
- 事実の照合と、読者にとっての読みやすさを点検する。環境が対応していれば、この二つは並行して進める。
- 点検結果を一人の担当者がまとめる。問題があれば下書きへ戻し、修正後は必要な点検をやり直す。
- 最終確認者が掲載内容を承認し、公開担当者へ渡す。
「文章ができたら公開」ではなく、必要な確認結果がそろったときに先へ進む関係をつくります。
- 資料確認不足 → 管理者へ確認・保留
- 執筆確定事項から下書き
- 点検事実と根拠読みやすさ同じ版を確認する
- 統合・最終確認問題あり → 執筆へ差し戻し
- 承認した稿を公開担当へ
渡すものを決めると、つなぎ目が見える
| 工程 | 受け取るもの | 次へ渡すもの | 進めない場合 |
|---|---|---|---|
| 資料確認 | 資料Aと依頼メモ | 事実・根拠箇所・未確認事項の表 | 必須情報を管理者へ確認する |
| 執筆 | 確定事項の表と文体条件 | 版番号を付けた下書き | 不明点を推測せず戻す |
| 点検 | 同じ版の下書きと根拠資料 | 問題箇所・理由・重要度の一覧 | 根拠不足は確認待ちにする |
| 統合・最終確認 | 下書きと点検結果 | 承認した最終稿 | 矛盾を解消するまで保留する |
担当が増えるほど、この「渡すもの」が大切になります。点検担当の片方が初稿、もう片方が修正稿を見ていたら、結果を単純には合わせられません。最終確認者は、どの版に対する結果かをそろえます。
並行にできること、順番を守ること
事実の点検と読みやすさの点検は、同じ下書きに対して分けて進められます。ただし、点検が終わる前に下書きを書き換えると、古い版への指摘が混ざります。いったん結果を集めてから修正し、その修正の影響を再確認する流れにします。
料金が未確認のまま料金説明を書き始めるなど、前の仕事の結果に依存する工程を、単に速くするために並行化するのは避けます。待つべき情報と、別々に進めてよい仕事を区別してください。
複数のAIが一致しても、同じ資料や思い込みを共有していれば、独立した検証になったとは言えません。異なる役割を割り当てることと、別の根拠で事実を確かめることは分けて考えます。
四つの設計を、一つの仕事で使う
ここまでの連載で、四つのメモができました。第2回の依頼メモ、第3回の作業環境の一覧、第4回の合格条件と修正記録、そして今回の作業図です。
これらを全部大がかりに実装する必要はありません。短い文章なら、一人が資料を渡し、AIの下書きを確認するだけで十分なこともあります。確認漏れが起きた、引き継ぎで条件が落ちた、といった具体的な問題に合わせて足していきます。
仕組みを増やした後は、最初と同じ基準で成果を比べます。未確認の主張や抜けは減ったか。確認時間や費用はどう変わったか。手順を複雑にしたのに改善が見えなければ、簡単な流れへ戻す判断も必要です。
Sofriaが大切にしたいのは、AIの出力を人が確かめ、仕事の目的に合う形で届けることです。まず一つ、繰り返し頼んでいる仕事を選び、情報と確認の流れを書き出してみてください。新しい用語を覚えるだけでなく、明日の依頼の仕方を変えるきっかけになればと思います。
