ブロックチェーンエンジニアのフリーランス案件の仕事内容|案件の種類と働き方
公開 2026-11-04 監修:株式会社エージェントベスト
フリーランスのブロックチェーンエンジニアの仕事は、取り消せない処理を扱うコードやシステムを、公開の前に誤りなく仕上げ、公開の後も見守ることが中心です。ただし、スマートコントラクトそのものを書くのか、その周りのサービスを作るのか、企業向けの分散台帳を組むのか、他人のコードを点検するのかで、1日の過ごし方も成果物も大きく変わります。
この記事では、案件を5つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。求められるスキルはブロックチェーンエンジニアに求められるスキル、報酬の決まり方はブロックチェーンエンジニアの報酬の記事で扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。
案件は5つの種類に分けると見通しやすい
「ブロックチェーンエンジニア募集」と書かれていても、中身は次のように分かれます。
| 案件の種類 | 主な相手 | 時間を多く使う仕事 |
|---|---|---|
| スマートコントラクトの開発 | テックリード、レビュー担当、外部の監査会社 | 設計、実装、テスト、公開の準備 |
| Web3サービスの周辺開発 | プロダクトの責任者、フロントエンド・インフラの担当 | API、ウォレット連携、データの集計、監視 |
| 企業向けの分散台帳 | 業務部門、参加企業の担当者、情報システム部門 | 参加組織と権限の設計、業務の整理、既存システムとの連携 |
| コードの監査・レビュー | 依頼元の開発チーム、監査のリード | コードの読み込み、攻撃の再現、報告書の作成 |
| 暗号資産を扱う業務システム | 業務部門、コンプライアンス担当、運用チーム | 入出庫や残高の管理、会計や監視の仕組みとの連携 |
以下の1日・1か月の流れは、典型的な例です。時間の配分は案件によって違うため、目安として読んでください。
スマートコントラクトの開発
1日・1か月の流れ(例)
朝はチームのチャットとプルリクエストのレビュー依頼を確かめ、午前中は設計書に沿ってコントラクトを実装します。午後はテストの追加と、レビューで受けた指摘への対応です。夕方に短い打ち合わせで、権限の持たせ方やアップグレードの方式など、後から変えにくい論点をそろえます。
1か月の単位では、仕様の確定、実装とテスト、内部のレビュー、外部の監査、公開という流れで進むことが多くあります。公開の前の週は、テスト用のネットワークでの最終確認と、公開手順の読み合わせに時間を使います。
成果物と、この種類ならではの点
コントラクトのコード、テスト、設計書(状態の持ち方、権限、止める手段)、公開と運用の手順書が主な成果物です。Solidityの公式ドキュメントは、セキュリティの推奨として、コントラクトを小さく分けること、異常時に止める仕組みを用意すること、第三者のレビューを受けることなどを挙げています。書く時間よりも、確かめる時間と説明する時間のほうが長いのが、この種類の特徴です。
Web3サービスの周辺開発
1日・1か月の流れ(例)
午前はバックエンドのAPIや、チェーンのデータを読み取って集計する処理の開発、午後は画面側の担当者とウォレット連携や取引の送信の流れをすり合わせます。チェーンへの記録は送った直後に確定するとは限らないため、確定を待つ間の表示や、失敗したときの再送の扱いを詰める打ち合わせがよく入ります。
1か月の単位では、短い周期で機能を出していくチームが多く、リリースの計画、実装、監視の見直しを繰り返します。
成果物と、この種類ならではの点
API、データの集計処理、監視の設定、障害時の手順などです。コントラクトを書く時間は全体の一部で、仕事の大半は一般的なWebのバックエンド開発であることも珍しくありません。周辺の言語の仕事の中身はGoエンジニアの仕事内容やTypeScriptエンジニアの仕事内容も参考になります。
企業向けの分散台帳
1日・1か月の流れ(例)
午前は業務部門や参加企業の担当者との打ち合わせで、どの会社がどの記録を見てよいか、どの承認があれば記録してよいかを整理します。午後は、その整理をもとにチェーンコードや参加組織の設定を作り、既存の業務システムとのつなぎ込みを進めます。
1か月の単位では、業務の整理、検証環境での試行、参加企業との確認会という流れが多く、実証実験の段階で終わる案件もあります。
成果物と、この種類ならではの点
業務の流れと権限の整理表、参加組織とデータの見え方の設計、チェーンコード、既存システムとの連携仕様などです。技術の話より、会社どうしの約束を仕組みに落とす話に時間を使います。打ち合わせの相手が業務部門や他社の担当者になるため、説明の資料をつくる時間も多くなります。
コードの監査・レビュー
1日・1か月の流れ(例)
依頼元から受け取ったコードと仕様を読み込み、気になる箇所に印をつけ、手元で攻撃を再現して確かめます。日々の作業は一人で黙々と進む時間が長く、監査のリードやほかの担当者と、見つけた点の重さをすり合わせる打ち合わせが入ります。
監査は期間を区切って進むことが多く、読み込み、指摘の洗い出し、報告書の作成、依頼元の修正の確認という流れになります。
成果物と、この種類ならではの点
指摘の一覧(重さ、再現の手順、直し方)、報告書、修正後の再確認の記録です。OWASPのSmart Contract Top 10(2025年版、2026年10月時点)に挙がるアクセス制御の不備や価格オラクルの操作などに照らすだけでなく、仕様と実装の食い違いまで見るのが仕事です。何を確かめ、何は対象外だったかを報告書に書き分けることも求められます。
暗号資産を扱う業務システム
金融庁は、国内で暗号資産と法定通貨の交換サービスを行うには暗号資産交換業の登録が必要だと案内しています(2026年10月時点)。こうした事業者や、暗号資産を扱う会社の業務システムの案件では、チェーンの技術より、入出庫の管理、残高の照合、会計や不正の監視の仕組みとの連携が中心になります。
1日の流れは一般的な業務システムの開発に近く、業務部門やコンプライアンス担当との仕様の確認、運用チームとの手順のすり合わせが入ります。成果物は、業務の要件書、連携の仕様、運用手順、監査や検査に備えた記録の残し方などです。作業場所や端末の決まりが厳しいことが多く、働き方はブロックチェーンエンジニアのリモート案件の記事で解説しています。
どの案件にも共通する仕事と、関わる相手
種類が違っても、次の仕事はほぼすべての案件にあります。
- 変更の理由を文章で残す:プルリクエストや設計書に、なぜ安全と言えるか、何は確かめていないかを書く
- 後から変えにくい判断を先にそろえる:権限、アップグレードの方式、データをチェーンに載せるかどうか
- 公開と運用の手順を守る:手順書に沿い、複数人で確かめながら進める
- 公開後を見守る:監視、異常時の連絡、必要なら止める判断の材料を出す
| 相手 | 出すもの |
|---|---|
| テックリード・CTO | 設計の選択肢と理由、リスク |
| レビュー担当・監査会社 | 変更の説明、指摘への回答と修正 |
| プロダクト・業務の責任者 | できることとできないこと、公開の見通し |
| 運用チーム | 手順書、監視の観点、障害時の連絡先 |
よくある質問
フリーランスのブロックチェーンエンジニアは、ずっとコントラクトを書いているのですか?
コントラクトだけを書く案件もありますが、多くはありません。周辺のAPIや集計処理、テスト、レビュー対応、手順書づくりに時間を使うことがほとんどです。チェーンに関わる作業の割合は、参画前に確かめておくと想定とのずれを防げます。
監査の案件は、開発の案件と比べて働き方がどう違いますか?
期間を区切って一人でコードを読み込む時間が長く、成果物は報告書になります。開発の案件のような日々の定例は少ない一方、報告の期限がはっきり決まっていることが多くあります。契約の形によって負う責任が変わるため、準委任契約と請負契約の違いも確かめておきましょう。
参画して最初の1か月は何をすることが多いですか?
リポジトリと設計書の読み込み、権限と公開の手順の確認、小さな修正やテストの追加から始めることが一般的です。初月の進め方はブロックチェーンエンジニアの参画初月にやることで解説します。
参考にした公的情報・資料
記事の内容は公開日時点の情報にもとづきます。制度や税率は変わることがあるため、手続きの前に必ず各機関の最新情報をご確認ください。