エンジニアの世界で、静かに揉めていること
海外の開発者ブログに、こんなタイトルの記事が上がって話題になった。私はもう、Claude Codeに自分自身を共著者として書き込ませるのをやめた、というものだ。
前提を補足しておく。プログラムの世界では、変更のひとまとまりをコミットという単位で履歴に登録する。コミットには、いつ・誰が・何を・なぜ変えたかが残る。この履歴は消さない限り何年も会社に残り、5年後でもこの一行を書いたのは誰か、を数秒で引ける。監査でも、トラブルの原因調査でも、退職者の担当箇所を引き継ぐときでも、最後に頼るのはこの履歴だ。
Claude Codeは、この履歴を自分で作る機能を持っている。そして初期設定のままだと、作った履歴の末尾に、Claude Codeが生成しました、という趣旨の一行と、Co-Authored-By: Claude という一行を自動で書き足す。共著者はClaudeです、という意味の記述だ。冒頭のブログの筆者は、これを切った。理由は速度でもコストでもない。履歴に残る名前は、責任の所在を示すものだ、という一点である。
この記事に多くの反応が集まったこと自体が、論点の広さを示している。賛成する人もいれば、記録として残すほうが誠実だと反論する人もいた。つまり、正解が確立していない。一見すると、プログラミングの現場でしか使わない機能をめぐる内輪の作法の話に見える。けれど私は、この議論こそ非エンジニアが読むべきものだと思っている。論点を言い換えれば、AIが手伝った仕事に、AIの名前を記録として残すのかどうかという話であり、それは提案書にも議事録にも請求書にも就業規則にも、まったく同じ形で降りかかってくるからだ。
共著者という言葉が引っかかる理由
反対する人たちの言い分は、大きく4つに整理できる。
1つめは、共著者という言葉が持つ意味だ。共著者は本来、その成果物について説明を求められたら答えられる主体を指す。バグが出たとき、法的な問い合わせが来たとき、なぜこう書いたのかと聞かれたときに、答える義務を負う人のことだ。AIはそれを負えない。負えない相手を共著者欄に書くと、責任の列に空席が1つ増えるだけになる。
2つめは、記録の実務が壊れることだ。開発チームは、誰がどのくらい書いたかの統計を、レビュー体制の設計や人員配置の判断に使っている。そこに人間ではないアカウントが毎回混ざると、数字の意味が薄まる。会社でいえば、営業成績の集計表にAIという名前の営業担当が毎月出てくるようなものだ。
3つめは、ツールが自社の宣伝文句を勝手に社内の記録へ書き込んでいる、という感覚的な反発だ。生成しましたという一行にはリンクまで付く。自分の会社の履歴なのに、他社の署名が残り続ける。これを気持ち悪いと感じる人は一定数いる。
4つめが、私が一番重いと思っている点だ。AIが書いた、という記録が残ると、それが言い訳として機能してしまう。人はレビューを甘くする方向に流れる。逆に、質の高い仕事だったのにAIの名前があるだけで軽く見られる、という不当な減点も起きる。どちらに転んでも、書いた本人が最終的に責任を持つ、という一番大事な線が曖昧になる。
非エンジニアにとっての本当の意味
ここからが本題だ。あなたの会社にgitは無いかもしれない。けれど、記録と署名は必ずある。
見積書には作成者の名前が入る。議事録には作成者と確認者が入る。就業規則の改定案には起案者が入る。顧客への月次報告には担当者名が入る。これらはすべて、その内容について聞かれたら答える人が誰かを示すための署名だ。そして今、その文書の初稿をAIが書く場面が急速に増えている。
そこで多くの会社が悩む。AI利用を明記すべきか、黙っているべきか。透明性のためには書くべきだという意見と、書くと信用を落とすという意見が社内で割れる。私が見てきた限り、この二択で議論している時点で、たいてい間違った問いを立てている。
正しい問いは、どこに書くかだ。成果物の表面と、社内の記録は、まったく別の役割を持っている。成果物の表面は、顧客に対して「この内容について私が答えます」と宣言する場所だ。ここにAIの名前を並べると、宣言が弱まるだけで、顧客の得にはならない。一方、社内の記録は、後から検証し、改善し、引き継ぐための場所だ。ここにAIの関与を残さないと、品質のばらつきが起きたときに原因を追えなくなる。
AIの関与は、成果物の顔ではなく、管理台帳に書く。これが私の結論だ。
隠蔽ではないかと感じる人もいると思う。だが考えてみてほしい。会計ソフトが自動仕訳した結果を顧問先に出すとき、決算書にこの仕訳はソフトが提案しましたとは書かない。書かないが、事務所の中では誰が承認したかを残す。同じ構造だ。道具が下書きし、人が確認して署名する。署名した人がすべてを引き受ける。
業種別に見ると、これは明日の話になる
抽象論では動けないので、具体的な現場に落とす。
10人規模の税理士事務所の場合。顧問先へ毎月出す月次報告のコメントを、担当者がAIに下書きさせるようになったとする。前月比の増減理由や、資金繰りへの注意点を200字でまとめる作業は、たしかにAIが得意だ。ここで報告書の末尾に本コメントはAIが作成しましたと書いてしまうと、顧問先が毎月払っているのは先生の見解に対する対価なので、価値が一気に薄れる。書くべきではない。ただし事務所の内部では、下書きがAIで、数字の突き合わせと最終確認を誰がやったかを必ず残す。翌年、その顧問先で数字の解釈が問題になったとき、辿れるのはそこだけだからだ。
従業員60名の建設会社の総務担当の場合。就業規則の改定案や、安全衛生に関する社内通達の初稿をAIに書かせるケースが増えている。労働基準監督署へ出す書類や社内規程に、AIが作成したという注記を入れる必要はない。むしろ規程は会社の意思表示なので、入れると効力の印象を弱める。一方で、改定履歴の管理表には「初稿はAI、条番号の原典確認は総務課長、法的確認は顧問社労士」と3行残す。法令の条番号や施行日は、AIが自信たっぷりに間違える代表格なので、誰が原典に当たったかを記録に残すこと自体が、事故を防ぐ仕組みになる。
20人規模のマーケティング会社の制作担当の場合。ここだけは事情が違う。クライアントへ納品するコピーや記事の場合、AI利用の可否や開示義務が契約書に書かれていることが増えてきた。生成AIの利用を禁止する条項、事前申告を求める条項、成果物にAI関与の記載を入れることを禁じる条項、どれも実在する。つまり書くか書かないかを社内の好みで決められない。契約が先で、運用が後だ。ここで危険なのは、ツールが初期設定のまま自動で署名を書き足す挙動である。担当者が意識しないうちに、契約に反する記載が納品物や納品物のファイル履歴に残る、という事故が起きうる。
従業員15名で食品のネットショップを運営する会社の、カスタマーサポート担当の場合。問い合わせ返信の下書きをAIに作らせる使い方は、すでに珍しくない。賞味期限の質問、配送遅延のお詫び、定期購入の解約手続きの案内。どれも型があるので相性がいい。ここでも返信メールの署名欄に、AIが作成しましたと入れる必要はない。顧客が知りたいのは、自分の問題が解決するかどうかだけだ。ただしクレーム対応だけは別扱いにしたほうがいい。返信文がそのまま言質になり、後から事実確認を求められる可能性があるからだ。クレーム案件に限っては、下書きの元になった情報をどこから取ったのか、送信前に誰が読んだのかを、対応履歴に一言残しておく。これは台帳を別に作る必要すらなく、既存の問い合わせ管理システムのメモ欄で足りる。
個人事業主のデザイナーやライターも構造は同じだ。取引先ごとに条件が違うので、案件ごとに一度確認しておくだけで、後から揉める確率が大きく下がる。
4つの現場を並べてみると、共通点がはっきりする。表面に書くかどうかは相手が誰かで決まり、内部に残すかどうかは後から検証する必要があるかで決まる。この2つを混ぜて考えるから、書くか書かないかの水掛け論になる。
そのまま使える、社内ルールの決め方
ここまでの話を、明日から回せる形にする。所要時間は最初の一回だけで30分程度だ。
ステップ1は、自社の成果物を3種類に仕分けることだ。社外に出す文書、社内だけの文書、規制や契約が絡む文書。この3つに分けて、それぞれ表面にAI関与を書くかどうかを決める。私の推奨は、社外に出す文書と社内文書は書かない、規制や契約が絡む文書は個別に確認する、である。全部に一律のルールを作ろうとすると必ず破綻するので、最初から3本立てにしておく。
ステップ2は、記録先を1か所に決めることだ。共有フォルダのスプレッドシート1枚で十分だ。列は、日付、成果物名、AIを使った工程、最終確認者、提出先。この5列だけでいい。AIを使った工程の欄には、下書き、要約、翻訳、データ整形、といった単語を1つ書く。ここを凝ると誰も書かなくなるので、選択肢を5個くらいに固定しておくとよい。入力は成果物を出した本人がやる。上長がまとめて後から埋める運用にすると、必ず形骸化する。1件あたり20秒で終わる設計になっているかを、導入して2週間後に一度確認してほしい。20秒を超えるなら列が多すぎる。
ステップ3は、最終責任者を必ず1名、人の名前で書くことだ。チーム名や部署名では意味がない。この文書について聞かれたら答える人が誰かを、1名に絞る。ここが空欄のまま出ていく文書があるなら、AI以前の問題として運用を直したほうがいい。
ステップ4は、月に1度、台帳を眺めることだ。目的は監視ではない。どの工程でAIが効いているかを知るためだ。たとえば議事録の要約だけ毎週20件並んでいるなら、その工程は仕組み化する価値がある。逆に、AI関与の記録が付いた文書だけ差し戻しが多いなら、確認手順に穴がある。
AI利用のルールは、禁止事項のリストではなく、記録の型として設計したほうが定着する。
ルールを守らせることではなく、後から辿れる状態を作ることが目的だと社内で言い切ると、書く側の抵抗が一気に減る。
Claude Codeの自動署名を止める設定
社内にプログラムを触る人がいて、Claude Codeを使っている場合の具体的な手順も書いておく。設定ファイルを1つ置くだけで、自動で書き足される署名を止められる。
すべてのプロジェクトで止めたいなら、パソコンのホームフォルダにある .claude/settings.json に、次の内容を書く。
{
"attribution": {
"commit": "",
"pr": ""
}
}
commit がコミット履歴の署名、pr がプルリクエスト（変更内容をチームに提出して確認してもらう仕組み）の説明文の署名にあたる。空文字を指定すると署名が付かなくなる。空文字ではなく自社のルールに合わせた文言を入れることもできるので、たとえば社内規程に沿った注記を1行だけ残す、といった運用も可能だ。
特定のプロジェクトだけ止めたいなら、そのプロジェクトのフォルダ内にある .claude/settings.json に同じ内容を書けばいい。設定は上書きされる。なお、以前は includeCoAuthoredBy という項目で同じことをしていて、これは今も動くが非推奨扱いになっている。これから設定する人は attribution を使ってほしい。
大事なのは設定そのものではなく、初期設定のままだと自動で何かが記録に書き込まれる、という事実を知っているかどうかだ。
よくある誤解と、つまずきやすい点
誤解の1つめは、AIの名前を消すのは隠蔽ではないか、というものだ。違う。ここで提案しているのは、書く場所を成果物から台帳に移すことであって、記録をなくすことではない。むしろ台帳に残したほうが、日付も工程も確認者も揃った形で残るので、成果物の隅に小さく一行入れるより透明性は高い。
誤解の2つめは、AIが作成しましたと書いておけば、間違いがあっても責任を軽くできる、というものだ。これは通用しない。顧客との関係でも、監督官庁との関係でも、責任を負うのは署名した事業者だ。道具の名前を書いても免責されない。むしろ、確認が甘かった証拠として使われる可能性のほうが高い。
誤解の3つめは、一律のルールを作れば終わる、というものだ。前述のとおり、契約や業界規制で条件が変わる。士業、医療、金融、教育、公共調達では、AI利用の申告が求められる場面がある。補助金申請やコンペの応募要項にAI利用に関する規定が入っていることもある。3種類に仕分ける、という設計にしているのはこのためだ。
誤解の4つめは、うちは小さい会社だから台帳のような大げさなものは要らない、というものだ。実際は逆だと思っている。10人以下の会社ほど業務が個人に張り付いていて、その人が休んだ日に誰も再現できない、という状態になりやすい。AIを使うと作業は速くなるが、頭の中で起きた判断はさらに見えなくなる。5列のスプレッドシート1枚は、大企業向けの管理ではなく、小さい組織が引き継ぎで詰まないための最低限の保険だ。規模が小さいほど、記録を残す作業そのものを軽くしておく必要はあるが、記録をやめていい理由にはならない。
つまずきやすい点も2つ挙げておく。1つは、後回しにすると直せなくなることだ。履歴やファイル名に自動で書き込まれた記述は、量が増えてから一括で消そうとすると手間もリスクも跳ね上がる。設定は最初にやる。もう1つは、決めたルールを口頭で伝えて終わりにしてしまうことだ。台帳のテンプレートを1枚作って共有フォルダに置き、記入例を1行入れておく。それだけで定着率が変わる。
まとめ
Claude Codeが自動で共著者欄に自分を書き込む挙動をめぐる議論は、表面的にはツールの初期設定の話だ。だが本質は、AIが日常的に仕事へ入り込んできた結果、誰が責任を持つのかという線をもう一度引き直す必要が出てきた、という話である。
私の結論は3つに集約できる。第一に、成果物の表面に書く名前は、責任を取る人の名前だけにする。第二に、AIをどの工程で使ったかは、社内の台帳に必ず残す。第三に、契約や規制が絡む文書だけは、個別に条件を確認してから決める。この3つを決めておけば、ツールが増えても運用は壊れない。
AIを使うことは、もう隠すことでも誇ることでもなくなった。電卓を使ったと申告しないのと同じ場所に、いずれ落ち着く。ただし、電卓と違ってAIは自信たっぷりに間違える。だからこそ、誰が確認したかという記録だけは、これまで以上に丁寧に残す価値がある。
冒頭のブログの筆者がやったことは、設定を1か所変えただけだ。所要時間でいえば1分もかからない。それでも記事が読まれたのは、その1分の裏に、自分が書いたものは自分が引き受けるという線を引き直す判断があったからだと思う。同じ判断を、私たちは自分の会社の文書についてもしなければならない。
自社の文書でAIをどこまで使ってよいか、記録をどう残すべきか。判断に迷っているなら、Claude Worksの無料30分相談で、御社の業種と文書の種類に合わせた線引きを一緒に整理します。現状の運用を伺ったうえで、明日から使える台帳のテンプレートまでお持ち帰りいただけます。
