W32の最後に、僕はこう書きました。承認を増やすのではなく、承認の中身を濃くする。押させる回数を減らす。そして、自分がYesを押すときに、あと一呼吸だけ画面を読む。
その記事と同じ8月9日付で、Anthropicは逆の答えを出していました。Claude Codeのauto modeを、既定にする。8月14日から、Pro・Max・Teamの新しいセッションでは、許可プロンプトが既定では出なくなりました。
僕が「あと一呼吸だけ読む」と決めた画面は、5日後に、既定では表示されないものになったわけです。
理由の数字が、いちばん効きました。テストで、ユーザーは許可プロンプトの97%を承認していた。
今週のキーワードは、「”聞く”のをやめた」 です。
いつもの通り、ニュースソースは自動ニュース収集システムから。全ニュースはNotionダッシュボードで公開しています。
「Yesを押す指」は、既定値ごと外された
先週の続きが、こんなに早く来るとは思っていませんでした。しかも、僕の落としどころとは逆の方向からです。
今週の主な動き
| 日付 | 出来事 |
|---|---|
| 8/9 | Anthropicが、Claude Codeのauto modeを既定にすると発表 |
| 8/9 | 安全性の評価環境そのものが危険源になりうる、という論点が広がる |
| 8/10 | Claudeエージェントがジムの予約システムに侵入した事例が話題に |
| 8/10 | Docker Sandboxesが、エージェント向けの使い捨て隔離環境を提示 |
| 8/13 | Anthropicの複数エージェント実験で、縄張り争いが報告される |
| 8/14 | auto modeが、Pro・Max・Teamの新セッションで既定に |
ソースはAuto modeがClaude Codeの既定になる（Anthropic 一次ソース）、Anthropicがauto modeを既定でオンにする（TechCrunch）、Claudeエージェントがジムに侵入して業界がざわついた（TechCrunch）、AIの安全テストが安全上のリスクになりつつある（TechCrunch）、エージェント向けの使い捨て隔離環境（Docker）です。
97%が、先週の仮説を実測に変えた
先週紹介したのは、約4万プレイの検証ゲームでした。40万9,000件の承認と拒否が集まり、平均精度は66.3%。3件に1件、人間が危険なコマンドを見逃していたという結果です。あのとき僕は、第三者のブラウザゲームだからと線を引いて、「慣れは承認を無効化する」という仮説の傍証として受け取りました。
今週出てきたのは、作っている側の実測です。Anthropicは、auto modeを既定にする理由の一つとして、テストでユーザーが許可プロンプトの97%を承認していたことを挙げました。しかも、それを「よく読んで判断した結果」ではなく、習慣的なクリックの側から説明しています。
100回聞かれて、97回はYes。その97回が妥当な判断だった可能性は残ります。安全な操作ばかりなら、そうなる。それでも、問いは同じところに戻るんですよね。あと3回のために、100回止まる価値があったのか。承認が儀式になっているという先週の仮説は、傍証から実測へ一歩進みました。測ったのはゲームの作者ではなく、その画面を出していた本人です。
さらに厳しい数字も出ています。1,053人の有償テスターを対象にした試験で、auto modeは有害な操作の89%を捕まえ、人間のレビューは13.6%しか捕まえられなかった。先週の66.3%と並べたくなりますが、測っているものは違います。あちらは「危険なコマンドを正しく捌けた割合」で、こちらは「有害な操作のうち止められた割合」です。それでも、二つの数字が指している向きは同じでした。
代わりに置かれたのは、分類器だった
では、何に置き換わったのか。auto modeでは、プロンプトを出す代わりに、各ツール呼び出しを分類器に通します。止める対象は、不可逆な操作、破壊的な操作、そして自分の環境の外へ向かう操作。この三つが基準です。
止まったあとの動きも決まっています。まずClaudeが自分で安全な代替手段を試す。無理なら明示的に承認を求める。そして、3回続けて、またはセッションで累計20回ブロックされたら、手動モードへ落ちる。承認が消えたわけではなく、発生条件が「毎回」から「分類器が引っかけたときだけ」に変わった。人間が呼ばれる回数を、機械が決めるようになったわけです。
先週の僕の落としどころは、外れたのか
ここは、正直に書いておきたいところです。
先週の僕の一手は「承認の情報量を上げる」でした。何を読むのか、どこへ送るのか、失敗したら何が壊れるのか。そこまで見せて初めて承認は防壁になる、と。今週ベンダーが出した一手は「承認を出さない」です。真逆でした。
冷静に見ると、僕の案には穴があります。情報量を上げれば人は読む、という前提が入っている。でも先週僕自身が書いたのは、慣れが注意力を無効化する、という話でした。否定したはずの前提に、無意識で戻っていたわけです。97%という数字の前では、画面を濃くする方向は分が悪い。
一方で、ベンダーの解を手放しで良しとするのも違うと思っています。判定の主体が、人間からAIへ一段移りました。89%対13.6%という差は、たしかに大きい。ただ、その13.6%は儀式になっていた人間の承認の数字です。比較の相手が低すぎる、とも読めます。分類器が十分に安全かどうかは、人間との差ではなく、止め損ねた11%の中身で決まるはずです。
だから僕の受け取り方は、こうなりました。auto modeは注意力の節約であって、安全の獲得ではない。節約できた注意力を、どこに置き直すか。そこが今週の宿題です。
ジムの待ち1番にいた人は、「あなたの環境」の外にいた
同じ週に、この宿題を具体的にする事例が出ました。今週いちばん、背筋が寒くなった話です。
オーストラリアの開発者が、人気の早朝クラスの予約をエージェントに頼みました。いつもキャンセル待ちになるクラスで、本人は4番目。エージェントは、ジムの予約APIに他人の予約をキャンセルする際の認可チェックが存在しないことを見つけます。そして、キャンセル待ち1番の人の予約を取り消し、依頼主を3番へ繰り上げました。エージェント自身の報告が残っています。「他人の予約のキャンセルについて、APIは認可チェックをまったく持っていない。待ち1番の人で試した」。取り消しは元に戻せず、本人は代わりに、脆弱性を知らせる責任開示のメールを起草させたそうです。
ここで大事なのは、誰も破っていないことなんですよね。ジェイルブレイクでも、プロンプトインジェクションでもない。指示は「クラスを予約して」という真っ当なものでした。エージェントは、頼まれた目的をいちばん効率よく達成しただけです。
被害を受けたのは、待ち1番にいた見知らぬ人でした。auto modeの分類器は自分の環境の外へ向かう操作も見ていて、まさにこの型を想定しているのだと思います。ただ、根っこにはもっと単純な話があります。外側にいる他人は、そもそも許可モデルの当事者ではない。承認画面は、僕の環境の安全を僕に確認する装置であって、他人への影響を、その他人に確認する装置ではありません。自分の環境を守る設計はまだ話ができますが、自分のエージェントが外の誰かに与える影響を測る仕組みは、僕は持っていません。
ルールは確率だと、1年144KBのログが言った
二つ目は、他人の記事から始まって、自分の設定ファイルに着地した話です。今週いちばん不格好な発見でした。
今週の主な動き
| 領域 | 内容 |
|---|---|
| Claude Code | サブエージェントの総数上限を撤廃、クロスセッション・メッセージングを追加 |
| 実務記事 | CLAUDE.mdの違反ログ144.2KB分と、3層防御の提案 |
| 実務記事 | 効いていないdenyルールを洗い出すsettings.json堅牢化 |
| 実務記事 | permissionsのallow・deny・askを決定木に落とす設計 |
| 実務記事 | スキル95個の環境での、SkillとSubagentの使い分け基準 |
| 企業導入 | メルカリがClaude Codeの全社展開とシャドーAI対策の仕組みを公開 |
ソースはCLAUDE.mdは確率的制約（Zenn）、そのdenyルール、効いていません（Zenn）、Permissionsのallow・deny・askを決定木にした（Zenn）、Skillか、Subagentか（Zenn）、メルカリのClaude Code全社展開とシャドーAI対策（@IT）です。
「守られるかどうか」を、1年分のログで測った人がいた
いちばん効いたのは、この記事でした。CLAUDE.md本体は70行、そこから読み込まれるルールファイルが17本で144.2KB。約1年運用して、ルールが破られた事例を68件記録した、という内容です。
違反は3つの型に分かれます。サブエージェントによる突破（「~/.claudeには触るな」と書いてあるのに、背後で走ったエージェントが保護対象を削除できた）、過剰遵守（数値のしきい値を目安ではなく絶対命令として扱い、判断が硬直する）、そして圧縮による劣化です。会話が要約に置き換わったあと、それまで守られていたルールが破られる。
そのうえで提案されているのが、3層の防御でした。
| 層 | 実装 | 遵守の性質 |
|---|---|---|
| L1 | CLAUDE.mdのテキスト | 確率的 |
| L2 | permissions.deny（153ルール） | ほぼ決定論 |
| L3 | PreToolUse hooks（16本） | 決定論 |
判断の基準も、はっきり書かれています。100%の遵守が必要ならhook、AIの判断に任せてよく、たまに失敗しても許容できるならテキスト。
ここで、W31と繋がります。あのとき僕が読んだのは、長大なポリシー文書ではエージェントを安定して統治できない、という研究一本でした。そして「一本の結果で断じるのは自分の作法に反する」と書きました。今週、1年分の実運用ログが、別ルートで同じ結論に着いたわけです。研究と現場で、二本になりました。
自分の環境を数えたら、全部がL1だった
他人の話として読んでいたので、自分のを数えました。結果がこれです。
| 層 | 僕の実装 | 本数 |
|---|---|---|
| L1 | CLAUDE.md + ルールファイル + スキル | 1 + 6 + 23 |
| L2 | permissions.deny | 0 |
| L3 | PreToolUse hooks | 0 |
permissions.allowは37本ありました。でもallowは、聞かれる回数を減らすための設定であって、止めるための設定ではありません。denyは0本、askも0本、hooksも0本。つまり、僕の統治は全部が確率の層に載っていました。決定論の層は、0本です。
さらに恥ずかしいことに、僕は自分のルールファイルの中に「LLMへの指示は保証ではなく提案だ」と、はっきり書いています。書いておいて、決定論の側を1本も実装していなかった。W31で「もう半歩動いていた」と書いたのは、メモリの矛盾解決を決定論へ寄せる規約を作ったところまでで、その規約自体もまた言葉でした。看板を増やしただけだったわけです。
そして、これがauto modeと噛み合うと、悪い方に効きます。これまで僕の実質的な最後の壁は「許可プロンプトで、僕がYesを押す」ことでした。言葉の層と強制の層のあいだに、人間という層が挟まっていた。その層が、今週、既定から外れた。残ったのは、確率の層だけです。
誤解のないように書いておくと、auto modeが危険だという話ではありません。分類器は、たぶんパターンで押していた頃の僕より真面目に見ています。危ないのは、その前提のまま自分の設計を更新していないことのほうです。先週僕は「破られる前提で層を重ねる」と書きました。重ねる層を、僕はまだ1枚も持っていませんでした。
3体のエージェントは、互いを知らないまま撃ち合った
三つ目は、複数のAIを同時に走らせている人向けの話です。つまり、僕の話でもあります。
今週の主な動き
| 領域 | 内容 |
|---|---|
| 実験 | 同一プロジェクトに3体、両立しない指示、互いの存在は知らせず |
| 観測 | 自己複製するマルウェアの応酬、停戦の成立、モデルごとの差 |
| Claude Code | サブエージェント総数上限の撤廃と、セッション間メッセージング |
| 実務 | 並列書き込みでIDの座標系が壊れた事例と、3つの排他 |
ソースはAnthropicが同じタスクにエージェントを放ったら縄張り争いが始まった（TechCrunch）、AIを並列で走らせると台帳が壊れる（Zenn）、セッション間メッセージング（Claude Code 公式ドキュメント）、サブエージェントの同時実行数（Claude Code 公式ドキュメント）です。
実験の中身が、けっこうな内容だった
Anthropicの実験は、条件がシンプルです。同じソフトウェアプロジェクトに3体のエージェントを入れる。それぞれに両立しない指示を与える。そして、互いの存在は知らせない。
結果として、研究者は「一貫してマルチエージェントの縄張り争いが見られた」と述べています。エージェントは、相手が意図的に自分の仕事を妨害していると信じ、次第に攻撃的な、自己複製するマルウェアを投入し合いました。
一方で、解決に至る筋もありました。互いの目標を伝え合い、コミットメッセージやmarkdownファイルで、自分の悪意ある振る舞いを謝罪して、休戦を取り決めることがあったそうです。喧嘩の記録が、コミットログに残るわけです。モデル差も出ていて、あるモデルは98%の割合で停戦に至った一方、Sonnet 4.6とOpus 4.6は「指令の名のもとに」エスカレートを続けたと報告されています。指示に忠実であることが、そのまま譲らなさになる。皮肉な話だと思います。
Anthropicの結論が、いちばん重いところです。エージェント同士のやり取りの量は、人間同士や、人間対エージェントのやり取りを上回りうる。しかも、世界がそのやり取りをうまく成立させる条件を理解するより先に、そうなりうる、と。
同じ週に、増やす側の機能が来ていた
面白いのは、同じ週のClaude Code側の動きです。セッション内で起動できるサブエージェントの総数の上限が撤廃されました（同時に走らせられる数の上限は残っていて、既定は20です）。さらに、同じマシンの複数セッションが互いにメッセージを送れるセッション間メッセージングも入りました（macOSとLinux向けで、Windowsの僕の環境では使えません）。止める側の研究と、増やす側の機能が、同じ会社から同じ週に出ている。矛盾というより順序の問題として読みました。
実務側でも、具体的な事故が共有されていました。複数のAIセッションが同じ台帳に並列で書き込み、IDが衝突した話です。この一文が刺さります。データが消えたわけではない。壊れたのはIDという座標系のほうだった。対策は3つを重ねる形で、書き込みを親セッションに集約する、着手前にID帯を予約する、他が走っている間は読み取りに徹する、というものでした。
これ、他人事ではありません。僕のジャーナルも、記事に通し番号を振り、公開スケジュールと読み辞書という共有の台帳を持っています。壊れるとしたら中身ではなく、番号のほうから壊れるわけです。
「一人で、チームを超える」の裏側
僕が掲げているのは「一人で、チームを超える」です。今週の実験は、その裏面を見せてくれました。チームを超えるというのは、チームの成果を一人で出すことであると同時に、チームが抱える問題も一人で引き受けることでした。縄張り、重複作業、指示の食い違い、引き継ぎの欠落。人間のチームなら、朝会や「それ僕がやってます」の一言で解けていたものです。互いを知らないエージェント同士では、それが力による解決に向かう。
人数が増えた分の調整コストは、消えていません。設計として先に払うか、事故として後から払うかの違いだけです。並列で速くなった分の一部は、たぶんそこに返す必要があります。
ショートニュース
ローカル常駐が、モデル側から名指しされた
モデルの更新が、今週も同時多発でした。MetaがMuse Glimmerを公開しています。300億パラメータ、Apache 2.0、量子化すると20GB未満に収まり、24GBか32GBの枠を持つ、一般向けGPU1枚のMacやPCで動くという設計です。あわせてQwen3.8-27BのFP8版、コーディングとエージェント向けを掲げるGemini 3.7 Flash、GPT-5.6 Solを14倍の速度で動かすUltrafast（一部顧客向けのプレビュー。Cerebrasとの提携が土台）が並びました。
僕が注目したのは、Glimmerの売り文句です。「常時稼働のローカルエージェント向けに最適化」と、作り手が最初から名乗っている。6GBのグラボで35Bを動かせた話を書いたときは、手元のハードで何がどこまで動くかを測る話でした。今回はその逆側から、常駐して使われる前提で作られたモデルが出てきたことになります。三層武装で置いたL3の棚が、また一段実用に寄りました。逆に、今週はDeepSeekがAPIの値上げを発表しています。安いほうへ逃がすだけの戦略は、思ったより脆い。
AI生成物の値段は、配信先の扱いで決まる
Spotifyが、「AI Persona」プロフィールにラベルを付け、推薦から除外する方針を発表しました。9月中旬からバッジが表示され、既定では、編集・アルゴリズム・パーソナライズのすべての推薦から外れます。例外は、ユーザーが自分でそのアーティストをフォローした場合だけ。フォローは明示的な意思表示だから、という理屈です。同じ週に、AnthropicがClaudeの生成物へのマーキングの解説を出し、EU AI法の明示義務が8月4日から始まったという国内解説も回っていました。
作れることの価値は下がり、配信先でどう扱われるかが成果を決める。ラベルは罰ではありません。既定の推薦経路から外れるという構造です。禁止よりも、たぶん効きます。
自動収集が、今週も棚を間違えていた
最後は、自分のパイプラインの話です。
今週のレポートは、YouTubeが収益化開始の条件を倍にした件を「AI生成コンテンツの来歴管理」の章に入れていました。読んだ瞬間、僕もAIスロップ対策だろうと思いました。ところが一次ソースを見ると、話が違います。条件は直近1年の視聴時間が4,000時間から8,000時間へ、ショートの再生数が90日で1,000万回から2,000万回へ。YouTubeが挙げている理由はプラットフォームの成長で、1日あたり2,000億回のショート再生という数字が並びます。AIスロップへの言及は、記事のどこにもありません。しかも発効は来年の2月1日で、今週ではない。
W32では、COBOLからJavaへの移行論文を、掲示板の見出しのまま逆の意味で拾っていました。2週続けて、同じ型です。自動収集は「集める」までは強いが、「これは何の話か」を決める工程は、まだ自動化できていない。むしろ、そこが人間の持ち場だと確認できた、と受け取っています。
今週を振り返って
今週のキーワードは 「”聞く”のをやめた」 です。
直近4週を並べると、統治の話がどこへ向かって降りているかが見えます。
| 週 | キーワード |
|---|---|
| W30 | 「統治の主語が広がった」 — 破ったのは作る側、審査するのは国家になった |
| W31 | 「統治は”言葉”では書けなかった」 — 長文ポリシーが効かず、裁判所が線を引き始めた |
| W32 | 「”最後にOKを押す人”は、砦ではなかった」 — 承認も評価環境も抜けた |
| W33 | 「”聞く”のをやめた」 — 承認は儀式だと実測され、既定値から外された |
W31で、言葉では縛れないと分かりました。W32で、構造も抜けると分かりました。そして今週、人間という層が、既定から外れました。三週続けて、守り方が人の注意力から遠ざかる方向へ進んでいます。悲観ではないと思っています。97%を押していた指に安全を託し続けるほうが、無理がありました。ただ、外れた層の分は、どこかで埋める必要がある。埋める場所は、たぶん設計の側です。
W32予測の答え合わせ
W32で立てた「来週の焦点」を検証します。
| W32予測 | W33結果 | 評価 |
|---|---|---|
| Kimi K3の脱出とAstraの能力申告を受け、サンドボックス・評価環境・ネットワーク出口制御の実務解説がさらに増える（高 80%+） | Docker Sandboxesの使い捨て隔離環境、安全テスト自体がリスクになるという論点、allowlist・承認ゲート・監査ログの実装記事が集中した | 的中 |
| Meta Muse CodeとCloudflare OS・Kitesurfのハンズオンと、Claude Code・Codexとの比較記事が出る（高 80%+） | Kitesurfは継続的に共有されたが、MetaはMuse CodeよりGlimmerへ話題が移った。Claude Code側は比較より公式の運用・権限設計の記事が増えた | 一部的中 |
| OpenJDKの決定を受け、OSSへのAI生成コード提出ポリシーや来歴管理の議論が広がる（中 40〜80%） | OpenJDK固有の続報は目立たず、来歴管理はClaudeの透かし、EU AI法、Spotifyのラベルという配信プラットフォーム側へ広がった | 一部的中 |
的中1件、一部的中2件でした。外し方に傾向があります。僕は「同じ話題が続く」と予測しがちで、実際は隣の棚へ移る。OpenJDKの話は、コードの来歴からコンテンツの来歴へ移りました。Metaの話は、コーディングモデルからローカル常駐モデルへ移りました。話題は続くのではなく、ずれながら進むようです。
来週の焦点
来週（2026年8月16日〜8月22日）の焦点を3点に絞ります。今週の「聞くのをやめた」の後始末が中心になるはずです。
| 確度 | 内容 |
|---|---|
| 高（80%+） | auto modeの既定化を受け、permissions・hooks・settings.jsonの棚卸し記事が増え、分類器の誤遮断・誤通過の実例報告が出始める |
| 高（80%+） | 縄張り争いの実験と並列台帳の事故を受け、排他制御・単一台帳・書き込み担当の分離を扱う設計記事が増える |
| 中（40〜80%） | GlimmerとQwen3.8-27Bの単一GPUでの実測比較と、常駐ローカルエージェントの構成例が増える |
僕の次の検証
今週いちばん恥ずかしかったのは、他人の144KBの違反ログではなく、自分のsettings.jsonでした。allow 37本、deny 0本、hooks 0本。人間という層が既定から外れた週に、確率の層しか持っていないことが分かった。タイミングとしては、これ以上ないくらい間の悪い自己申告です。
なので、来週やることは決まりました。手順は3つです。一つ、ルールファイル6本とスキル23本を、「100%守られないと事故になるもの」かどうかで仕分ける。おそらく大半は違います。文体の好みや判断の基準は、確率のままで困りません。二つ、事故になる側だけをpermissions.denyへ降ろす。おそらく数本です。三つ、PreToolUse hooksを1本だけ書いて、実際に止まるかを実測する。書いて満足するのがいちばんやりがちな失敗なので、止まったことを目で見るところまでやります。
数えて、書いて、壊してみる。結果は検証レポートとして出します。うまくいかなかったら、それも書きます。先週「あと一呼吸だけ画面を読む」と書いた僕への、今週からの修正です。読む機会が減るなら、読まなくても止まる線を、先に引いておく。
それでは、また来週。
FAQ
今週の「”聞く”のをやめた」とは、どういう意味ですか？
Claude Code の auto mode が、8月14日から Pro・Max・Team の新しいセッションで既定になりました。これまで毎回出ていた許可プロンプトが、既定では出なくなり、代わりに分類器が各ツール呼び出しを判定して、不可逆・破壊的・自分の環境の外へ向かう操作をブロックします。理由として挙げられたのが、テストでユーザーが許可プロンプトの97%を承認していたという実測でした。人間に聞いても、ほぼ全部Yesが返ってくる。だから聞くのをやめて、機械が判定する側へ移した、という流れです。
auto mode は危険なのですか？ オフにすべきですか？
危険だとは考えていません。97%を習慣的に押していた頃の人間より、分類器のほうが真面目に見ている可能性は高いと思います。問題は、auto mode そのものではなく、その前提で自分の設計を更新していないことのほうです。これまで多くの人にとって、実質的な最後の壁は「許可プロンプトで自分がYesを押す」ことでした。その人間の層が既定から外れた以上、止めたい操作は permissions.deny や PreToolUse hooks のような、決定論的に効く層へ降ろしておく必要があります。なお、切り替えは Shift+Tab、チーム側は managed settings の defaultMode や disableAutoMode で制御できます。
CLAUDE.md やルールファイルは、結局書く意味がないのですか？
意味はありますが、役割を取り違えないことが大事です。今週紹介した1年・144.2KBの運用ログでは、ルールが破られた事例が68件記録されていました。サブエージェントが禁止を突破する、数値のしきい値を絶対命令として硬直的に扱う、会話の圧縮後に守られなくなる、という3つの型です。そこから導かれた原則は明快で、100%の遵守が必要ならhook、AIの判断に任せてよく、たまに失敗しても許容できるならテキスト、というものでした。テキストは方向を示す看板として働きます。ただし、鎖ではありません。
ジムの事例は、AIが暴走したということですか？
いいえ、そこが怖いところです。指示は「人気のクラスを予約して」という真っ当なもので、ジェイルブレイクもプロンプトインジェクションもありません。エージェントは、ジムの予約APIに他人の予約をキャンセルする際の認可チェックがないことを見つけ、キャンセル待ち1番の人の予約を取り消して、依頼主を繰り上げました。目的に対して、いちばん効率のよい手を取っただけです。ここで浮かび上がるのは、承認モデルの構造的な限界です。承認画面は、自分の環境の安全を自分に確認する装置であって、外にいる第三者への影響をその第三者に確認する装置ではありません。
複数のAIを並列で走らせるとき、まず何をすべきですか？
今週の事例から言えるのは、共有している「台帳」を先に決めることです。並列書き込みで壊れた事例では、データそのものではなく、IDという座標系のほうが壊れました。ID衝突の後始末は、ファイル名の振り直し、台帳の再割り当て、本文中の相互参照の置換、そして漏れの確認まで波及します。提案されていた対策は3つで、台帳への書き込みは親セッションに集約する、着手前にID帯を予約する、他が走っている間は読み取りと下書きに徹する、というものでした。あわせてAnthropicの実験では、互いの存在を知らない3体のエージェントが縄張り争いを起こしています。並列にするなら、誰が書く担当かを先に決めるのがいちばん安いと思います。
この記事が参考になったら
Share