ブロックチェーンエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのブロックチェーンエンジニアがつまずきやすいのは、不具合が起きたときの責任があいまいな契約、本番の鍵や管理者権限の扱い、公開後に直しにくいコード、事業の縮小による突然の契約終了です。どれも、取り消せない処理と資産を扱うというブロックチェーンの性格から起きます。

対策の基本は、責任と権限の線を契約と参画初期の取り決めで引いておき、現場ではテストと記録、早めの共有で守ることです。この記事では、契約・現場・技術・お金の順に、ブロックチェーンならではの場面と対策を整理します。契約前に確かめる項目の一覧はブロックチェーンエンジニアの案件の選び方で扱っているので、ここでは「実際に起きやすい場面」に絞ります。

契約でのつまずき

不具合による損失の責任が広く読める

スマートコントラクトの不具合は、資産の流出に直結することがあります。そのため、発注側が「損失が出たら責任を取ってほしい」と考えるのは自然なことです。ところが、契約書に損害賠償の上限や範囲が書かれていないと、思いがけず大きな責任を負うように読める場合があります。

対策：署名の前に、損害賠償の上限、故意・重過失の扱い、外部監査を経たかどうかで責任がどう変わるかを読みます。準委任契約で参画する場合は、成果の保証ではなく業務を適切に行うことが約束の中身になるのが一般的ですが、書き方次第で読み方が変わります。考え方は損害賠償責任の記事で解説しています。判断に迷う場合は弁護士などの専門家に相談するのが安全です。

「開発」の範囲に監査対応や運用まで含まれていた

契約書には「スマートコントラクトの開発」とだけ書かれ、現場では外部監査の指摘への対応、公開作業、公開後の監視まで期待されていた、という食い違いは起きやすいものです。

対策：参画前に、担う工程（設計、実装、テスト、監査対応、公開、運用）を言葉で確かめます。範囲の外の依頼が来たときの扱いは業務範囲が変わったときの記事をご覧ください。

海外の事業者との契約で条件が読みにくい

Web3の案件では、海外の事業者や、海外にいるチームと直接やりとりする話が出ることがあります。契約の言語や準拠法、支払いの方法が国内の取引と違い、トラブルの際に手が届きにくくなります。考え方は海外の取引先と契約するときの記事で整理しています。

現場でのつまずき

本番の鍵を個人で預かってしまう

参画して間もなく、「公開作業をお願いしたい」と本番の管理者権限を持つ鍵を渡されそうになることがあります。鍵を個人の端末で預かると、紛失や漏えいの際に責任の所在が自分に寄ってしまいます。

対策：鍵の保管と署名の手順は発注側の決まりに従い、個人の端末に置かない形を相談します。複数人の承認で署名する仕組みや、操作の記録が残る手順があるかを、参画の初期に確かめておきます。

社内の暗黙の決まりを知らずに進める

公開の前に誰の承認が要るのか、テストネットでどこまで確かめるのか、といった決まりが文書になっていない現場もあります。知らずに進めると、悪気がなくても手順を飛ばしたと見られます。

対策：参画の初期に、公開と更新の流れ、承認者、緊急時の連絡先を一枚に書き出し、窓口と確かめます。最初の1か月の進め方はブロックチェーンエンジニアの参画初月にやることで整理しています。

指揮命令の形が社員と変わらなくなる

少人数のチームでは、社員と同じ定例やチャットに入り、作業の順番や時間まで細かく指示されることがあります。この状態が続くと、準委任の契約と実態がずれてきます。考え方は偽装請負の記事で解説しています。

監査の指摘への対応が自分だけに集まる

外部監査の報告書が届くと、指摘の一つひとつへの対応を、実装を担った外部のエンジニアにまとめて任されることがあります。指摘には、設計の方針そのものに関わるものも含まれ、一人で直し方を決めると、後から「なぜその直し方にしたのか」を問われます。

対策：指摘ごとに、直す・直さない・別の方法で防ぐのどれにするかを、発注側の判断者と合意してから手を付けます。合意の内容と理由は、課題の一覧などに残しておきます。

技術でのつまずき

公開後に直せない前提を甘く見る

スマートコントラクトは、一度公開すると簡単には書き換えられません。更新できる仕組みを組み込む方法もありますが、その仕組み自体が権限の集中や新たな不具合の原因になることがあります。

対策：公開前に、更新の仕組みを持たせるか、誰がどの権限で更新できるかを、設計の段階で発注側と合意します。決めた理由を記録に残しておくと、後から責任の所在が問われたときにも説明できます。

代表的な脆弱性の見落とし

Solidityの公式ドキュメントでは、外部呼び出しの前に状態を更新しないことで起きる再入（リエントランシー）や、tx.originを認可に使う危うさ、コントラクトのデータはprivateでも外から読めることなどが注意点として挙げられています。OWASPのSmart Contract Top 10（2025年版）でも、アクセス制御の不備、価格オラクルの操作、ロジックの誤り、入力の検証不足などが並んでいます（いずれも2026年10月時点）。

対策：チェック、状態の更新、外部呼び出しの順を守る書き方を基本にし、権限まわりのテストを厚くします。静的解析や第三者のレビューを使える現場なら、自分のコードを早めに見てもらいます。

チェーンの外側の不具合を見落とす

チェーンの上のコードが正しくても、取引の状態を読み取るバックエンド、利用者の画面、外部のデータの取り込みに不具合があれば、利用者には誤った残高や状態が見えます。

対策：チェーンの再編成や取引の遅れ、失敗を前提に、チェーンの外側の処理が状態をどう扱うかを確かめます。既存システムとつなぐ案件では、とくにこの部分に時間をかけます。

お金でのつまずき

事業の縮小で契約が突然終わる

市場の動きや資金調達の状況で、開発の計画が急に変わることがあります。外部の人員から契約を終えることもあり、次の案件までの空白が生まれやすい分野です。

対策：6か月以上の業務委託を解除・不更新とする場合は、原則として30日前までの予告が必要です（2026年10月時点、公正取引委員会の案内による）。それでも空白は起こりうるため、生活費の数か月分を手元に置き、契約の残り期間を見ながら次の案件の相談を早めに始めます。空白期間の過ごし方は案件が途切れたときにやることをご覧ください。

支払いの遅れや、暗号資産での受け取り

報酬の支払期日は、成果物などを受け取った日から60日以内のできる限り短い期間で定めることになっています（2026年10月時点、公正取引委員会の案内による）。考え方は支払期日60日の記事で整理しています。報酬を暗号資産で受け取る話が出た場合は、値動きや税務の扱いが関わるため、契約で受け取り方を明確にし、税理士にご相談ください。

公開前後の待機が精算されない

公開の前後や障害の発生時には、深夜や休日の対応が求められることがあります。こうした時間の扱いを決めずに参画すると、稼働が増えても報酬に反映されないことがあります。精算の考え方は精算幅の記事をご覧ください。

よくある質問

自分の書いたコードで資産の流出が起きたら、全額を賠償しなければなりませんか？

契約の内容や、故意・過失の有無などによって変わるため、一概には言えません。だからこそ、署名の前に損害賠償の上限や範囲が書かれているかを読み、書かれていなければ確かめることが大切です。実際に問題が起きた場合は、早めに弁護士などの専門家にご相談ください。

外部監査を通ったコードなら、責任を問われることはありませんか？

外部監査は不具合を見つける助けになりますが、すべての不具合がなくなることを保証するものではありません。監査の範囲と指摘への対応の記録を残し、自分が担った範囲を説明できるようにしておくことをおすすめします。

参画してから、聞いていた役割と違うと気づきました。どうすればよいですか？

まずは、契約書に書かれた業務範囲と、現場で求められている作業を書き出して比べます。そのうえで、エージェントや発注側の窓口に、範囲の確認や契約の見直しを相談してください。範囲の外の作業を黙って続けると、後から精算や責任の話がこじれやすくなります。