書き上げたAPIリファレンスを次の打ち合わせで見せようと、契約書を見返しました。成果物の扱いを定めた条項を前にして、この文書を手元の見本に載せてよいのか、手が止まります。テクニカルライターとしてフリーランスの業務委託を受けるなら、書いた文書が実績になるかどうかは、いちばん気になるところです。技術文書の実績は、書いた後ではなく、受ける前に決まります。

1. テクニカルライターの実績が見せにくい理由

署名の付かない文書が中心になる

製品マニュアルやAPIリファレンスは、製品の一部として世に出ます。画面に表示される文言や、開発者向けのドキュメントサイトに載る文書には、書き手の名前が入らないことが多く、誰が書いたのかは外から分かりません。ここからは書き手の見立てです。

署名がなければ、「この文書を書いたのは自分です」と示す手がかりが手元に残りません。たとえば、公開されているマニュアルの一章を担当したとしても、担当した範囲は発注元とのやり取りの中にしか記録されないでしょう。

公開前の仕様を含む文書は外に出せない

もう一つの壁は、文書の中身そのものです。発売前の製品の仕様や、社外に出していないAPIの挙動を書いた文書は、完成してからも公開されません。社内の手順書も同じで、書いた本人であっても、次の打ち合わせの席で画面に映すことは難しい文書です。

一方で、公開されない文書だから実績にならない、とは限りません。見せられるかどうかと、実績として語れるかどうかは別の問題です。第6節で、文書そのものを見せられなくても実績を言葉にする形を整理します。

文書の種類で見せやすさが分かれる

技術文書と一口に言っても、種類によって世に出る形が違います。製品マニュアルは公開されますが、社名と製品名が文書に出ます。API文書は公開されるものと非公開のものがあり、社内の手順書は社外に出ません。技術記事には署名が付く場合があります。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

次は、書いた文書の著作者が誰になるのかを、文化庁の解説で確かめます。

2. 書いた文書の著作者は受注者側になる

委託して書いた場合の著作者

文化庁の著作権テキスト（令和8年度版）は、著作物の創作を他人や他社に委託した場合について説明しています。料金を支払ったかどうかにかかわらず、実際に創作した受注者側が著作者になるという内容です¹。業務委託でテクニカルライターとして文書を書く場合、書いた人が著作者になるのが制度の出発点です。

ただし、これは制度の一般的な解説です。個別の契約で権利がどちらにあるかは、契約の中身で決まります。成果物の権利を発注元へ譲渡する書き方は、別の記事で整理しています。

発注者側が納品後に使うための契約

同じテキストは、そのため発注者側が納品後に著作物を利用するには、そのための契約をあらかじめ交わしておく必要があると説明しています。例として挙げられているのは、自社のコピー機による増刷です¹。主体は発注者側で、使う側が契約を用意する、という向きの話です。

書き手の側から見れば、納品したあとの文書がどう使われるかは、契約で決まる部分が大きいということです。次の仕事の見本に載せたいときも、まず契約書の成果物の扱いを読む必要があります。

場面ごとの文化庁の説明

二つの説明を、場面で並べると次のとおりです。左の列が場面、右の列が文化庁のテキストの説明です。個別の契約の判断ではなく、制度の一般的な解説である点に注意してください。

場面	文化庁のテキストの説明
文書の創作を委託して書いた場合	実際に創作した受注者側が著作者になる
発注者側が納品後に使う場合	そのための契約をあらかじめ交わしておく

文書を書いた人が著作者になる制度を踏まえて、次は生成AIで下書きした部分の扱いに進みます。

3. 生成AIで下書きした部分の扱い

文化庁の著作物性の考え方

技術文書の下書きに生成AIを使う場面が増えています。文化庁の著作権テキストは、AI生成物の著作物性の考え方を整理しており、人間がAI生成物に創作的表現といえる加筆・修正を加えた部分については、通常、著作物性が認められると考えられるとしています¹。

この整理は考え方であり、個々の文書の判断ではありません。生成AIを使った文書は、どの部分にどれだけ人の手が入ったかで見方が分かれる、という点を押さえておけば足ります。

総務省のガイドラインの指針

総務省のAI事業者ガイドラインは、生成物について、他者の知的財産権等を侵害する可能性があること等にも留意しつつ、その利用に際し人間の判断を介在させる等の対策を講じるとしています²。文化庁の説明が著作物性の考え方であるのに対し、こちらは生成物を使うときの対策の指針です。

二つは別の資料で、扱っている問いも違います。一つの結論に束ねて読まず、文書を書く工程のどこで人の判断を挟むかを考える材料として並べて見るのが、読み違いを防ぐ読み方です。

出典：文化庁「著作権テキスト」、総務省「AI事業者ガイドライン」をもとに作成

受ける前に発注側と合意しておく

生成AIを使うかどうか、使うならどの工程までかは、受ける前に発注側と合意しておくと、後の行き違いを避けやすくなります。これは書き手の見立てで、法律の義務として決まっていると言っているわけではありません。

たとえば、下書きにだけ使うのか、校正にも使うのかを先に確かめます。発注側が生成AIの利用を前提にしているのか、控えてほしいのかは、案件ごとに違います。契約書に書かれていなければ、打ち合わせで尋ねる価値のある点です。

では、契約の中で何が明示されるのでしょうか。次の節で確かめます。

4. 契約で明示される取引条件を確かめる

明示するのは発注する側の義務

公正取引委員会のフリーランス・事業者間取引適正化等法Q&Aは、業務委託事業者がフリーランスに明示する事項を挙げています。双方の名称、業務委託をした日、給付や役務の内容などです³。明示する義務は発注する側にあり、フリーランスが書き出す義務ではありません。

受ける側の仕事は、届いた内容を読み、技術文書の仕事として足りているかを見ることです。自分がこの法律でいう特定受託事業者に当たるかどうかは、取引の形で変わるため、この記事では判断しません。

技術文書で決めておく中身

下の表は、明示される事項のうち三つについて、技術文書の仕事で何を決めておくとよいかを並べたものです。右の列は書き手の見立てであり、Q&Aに書かれた内容ではありません。給付や役務の内容は、文書の種類だけでなく、対象の製品や版まで書いてあると、後で話がずれにくくなります。

明示事項	技術文書で決めておくこと（書き手の見立て）
双方の名称	発注元の名称と自分の名称が、契約書の記載と合っているかを確かめる
業務委託をした日	双方が合意した日を確かめる
給付・役務の内容	文書の種類、対象の製品や版、形式、生成AIの使い方、権利の扱いを確かめる

明示事項に違反があった場合の運用状況は、別の記事で整理しています。契約が整ったあとは、権利を渡すときの対価の決まり方を確かめます。

5. 権利を渡すなら対価もいっしょに決まる

対価を協議せずに低く決める場面

公正取引委員会のQ&Aは、発注する側が成果物に関する権利の譲渡や許諾を受ける場合を取り上げています。その権利の対価を、フリーランスと協議することなく、一方的に通常支払われる対価より低い額に定めたときは、法律上問題となるおそれがある場合として説明されています³。

ここで押さえたいのは、権利を渡すこと自体ではなく、対価を協議せずに決める点が問題の焦点だという読み方です。額の目安はQ&Aの該当部分から読み取れないため、この記事でも金額には触れません。

権利がフリーランス側にあるのに二次利用される場面

もう一つは別の場面です。同じQ&Aは、知的財産権がフリーランスにあるにもかかわらず、発注する側が対価を支払わずに成果物の二次利用を行うことなどによって、フリーランスの利益を不当に害する場合を挙げています。不当な経済上の利益の提供要請として、法律上問題となるおそれがあるとされています³。

先ほどの場面は権利の譲渡や許諾を受けるときの対価の話で、こちらは権利が手元に残っているのに対価なしで使われる話です。どちらも問題となるおそれがある場合として説明されているだけで、個別の取引が該当するかどうかは、この記事では判断しません。

出典：公正取引委員会「フリーランス・事業者間取引適正化等法 Q&A」をもとに作成

契約書で権利と対価をそろえて読む

書き手の見立てとして、契約書では権利の扱いと対価の定めを、別々の条項としてではなく並べて読むと、行き違いに気づきやすくなります。成果物の権利をどちらが持つのか、納品後の利用に対価がどう結びつくのかを、受ける前に尋ねる場面は実務で起きるはずです。

権利と対価の確かめ方を押さえたところで、実績として見せる形に話を移します。

6. 実績として見せる形を決めておく

文書を見せられなくても言葉にできる実績

文書そのものを見せられなくても、実績の伝え方は残ります。誰向けに、どんな種類の文書を、どの工程で担ったのかを言葉にする方法です。たとえば、開発者向けのAPIリファレンスの構成案づくりから校正までを担当した、という書き方なら、発注元の公開前の情報を含めずに済みます。これは書き手の見立てです。

エンジニア出身の書き手にとっては、技術を理解したうえで書いた、という点が経験の厚みになります。実績を並べる一般的な方法は、別の記事のポートフォリオの材料で整理しています。この記事では、技術文書に特有の迷いに絞ります。

見せ方ごとに確かめること

見せ方によって、受ける前に確かめることが変わります。社名と文書の種類を職務経歴書に書くなら、社名を出してよいかが論点です。公開済みの文書のURLを示すなら、自分が書いたと言ってよいか、抜粋を見せるなら、秘密保持の範囲が論点になります。

著作権を持っていても、見せられない場合があります。文書の権利と、取引上守る範囲は別の話で、秘密保持の取り決めにも左右されます。秘密保持の中身は、この記事では扱いません。契約書で確かめてください。

見せ方	受ける前に確かめること（書き手の見立て）
社名と文書の種類を職務経歴書に書く	社名を出してよいか
公開済みの文書のURLを示す	自分が書いたと言ってよいか
抜粋を見せる	秘密保持の範囲に収まるか
自分で書いた見本を作る	先方の情報を含めていないか

では、これまでの確認をどんな順番で進めればよいのでしょうか。

7. 受ける前に決める順番

確かめる順に並べた5つの段階

文書の種類と公開範囲を先に確かめ、次に生成AIの使い方、権利と対価、実績として見せる範囲の順に進み、最後に契約の明示を確かめます。この順番は書き手の見立てで、制度が定めた手順ではありません。

実際の確認で使った資料は、文化庁の著作権テキスト、公正取引委員会のQ&A、総務省のAI事業者ガイドラインの三つです。それぞれ扱う問いが違うので、一つの結論に束ねず、段階ごとに別の資料を当てはめます。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

手が止まる前に尋ねる

冒頭の場面に戻ります。次の打ち合わせでAPIリファレンスを見せたくなったとき、契約書の前で手が止まるのは、受ける前に決めていなかった項目があるからです。五つの段階のどこかで尋ねておけば、見せてよいかどうかの答えは、契約書を開く前に手元にあります。

Remogu（株式会社LASSIC運営）は、リモートワーク案件特化のエンジニアマッチングで、案件の90%以上がフルリモート可能です。設計や開発の案件に参画しながら、文書を書く工程を担う形も探せます。まずは登録して、自分の経験に合う条件を確かめてみてください。

技術文書の実績は、書いた後ではなく、受ける前に決まります。

8. よくある質問

見せられる文書がまだ無いときはどうすればよいですか

自分で書いた見本を作る方法があります。先方の情報を含めず、公開されている技術を題材にして、書く工程と構成の考え方が伝わる形にします。これは書き手の見立てで、見本があれば仕事につながる、と言い切れる話ではありません。

生成AIで下書きしたことを発注側に伝える必要はありますか

伝えることを定めた法律の義務について、この記事で示せる資料はありません。書き手の見立てとして、受ける前に使い方を合意しておくと、後の行き違いを防ぎやすくなります。下書きだけに使うのか、校正にも使うのかを、発注側と先にそろえておく形です。

エンジニアの案件と並べて受けられますか

書き手の見立てでは、設計や開発の案件の中で、文書を書く工程を担う形もあります。エンジニアとしての経験が、技術を理解したうえで書く場面で役立ちます。稼働の配分や契約上の扱いは案件によって異なるため、受ける前に確かめてください。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 文化庁「著作権テキスト」（2026年5月21日・2026年10月確認）
＊2 総務省「AI事業者ガイドライン（第1.2版）」（2026年3月31日・2026年10月確認）
＊3 公正取引委員会「フリーランス・事業者間取引適正化等法 Q&A」（2026年8月26日・2026年10月確認）