Rustの案件を検索すると、速さだけでなく壊れたときの扱いまで問われる案件が目に入ります。エンジニアとして気になるのは、なぜこの技術が選ばれているのかという理由です。実際の統計を追うと、選ばれている場所には共通する条件が見えてきます。条件を知らないまま参画すると、想定していなかった厳しさに戸惑うこともあります。この記事では、その条件と、受ける前に確かめておきたい順番を整理します。

1. 集まるのは、壊れたときの損害が大きい場所です

10大脅威の上位に挙がる攻撃

IPAが毎年公開している「情報セキュリティ10大脅威」は、実際に報告された被害をもとに、組織が特に注意している対象を順位で示す一覧です。上位には、壊れたときの影響が大きい攻撃が並びます。案件を受ける側にとっては、どの技術が求められるかを見る前に、まずこの一覧を確認しておく価値があります。

2026年版で最も上位に置かれているのは、ランサム攻撃による被害です。11年連続、通算11回目の選出になります²。長期間にわたって上位から外れない攻撃だと分かります。

4位に挙げられているのが、システムの脆弱性を悪用した攻撃です。6年連続、通算9回目の選出です¹。ソフトウェアの内部にある弱点そのものが、狙われる対象になっています。

速さでなく、壊れ方の許容度が基準になります

Rustが検討される理由として語られやすいのは処理の速さですが、案件の条件を見比べると、それだけでは説明がつきません。速さよりも、壊れたときにどこまで影響が広がるかという点のほうが、選ばれる基準として重くなっています。

ランサム攻撃も脆弱性を悪用した攻撃も、一度侵入を許すと被害の範囲が読みにくい点で共通しています。壊れ方を制御できる設計が求められる場所ほど、選択の基準が厳しくなります。

この基準は、参画前の面談の質問にも表れます。機能が動くかどうかだけでなく、障害が起きたときにどこまで影響を止められる設計かを尋ねられる場面が増えています。これまでの案件で、壊れ方を意識した設計をどう説明してきたかが、そのまま評価の材料になります。

次に見るのは、その厳しさが自社だけでなく、委託先にも及んでいる点です。

出典：IPA「情報セキュリティ10大脅威 2026」（2026年1月）をもとに作成

2. 委託先も、攻撃の経路として見られています

サプライチェーンや委託先を狙う攻撃

10大脅威2026で2位に置かれているのが、サプライチェーンや委託先を狙った攻撃です。8年連続、通算8回目の選出になります³。自社の対策だけでは防ぎきれない領域として、上位に居続けています。

委託先が攻撃の入口として見られているという事実は、開発を任せる側の視点だけでなく、開発を受ける側の視点でも重い意味を持ちます。受ける側の設計品質が、委託元全体のリスクに直結する場面が増えています。

連携する仕組みが多い案件ほど、外部とやり取りする境界の設計が細かく問われます。何を受け取り、何を返すかという範囲を明確に区切っておくことが、委託先という立場での基本的な備えになります。境界があいまいなまま進めると、問題が起きたときにどちらの範囲かを切り分けにくくなります。

脆弱性を悪用した攻撃との重なり

4位の脆弱性を悪用した攻撃¹と、2位の委託先を狙った攻撃³は、別の項目として数えられていますが、経路としては重なる部分があります。委託先のソフトウェアに残った弱点が、そのまま侵入の入口になり得るためです。

順位表だけを見ると別々の脅威に見えますが、開発を受ける側から見れば、どちらも自分が書いたコードの弱点がどこまで広がるかという同じ問いにつながります。

委託先という立場を意識した設計経験があるかどうかは、参画前の会話で具体的に確かめられることがあります。外部から連携する仕組みをどう区切り、どこまでを自分の担当範囲として説明できるかが、これまでの経験のうち特に効いてくる部分です。

順位を並べて分かること

情報セキュリティ10大脅威2026のうち、開発を受ける側に関わりが深い2つの項目を並べると、共通点が見えます。順位そのものよりも、選出が続いている年数に注目すると、一時的な流行ではなく、継続して警戒されている対象だと分かります。次の表は、この2つの項目を順位と選出の連続性で並べたものです。

攻撃の種類	順位	選出の連続性
サプライチェーンや委託先を狙った攻撃	2位	8年連続、通算8回目3
システムの脆弱性を悪用した攻撃	4位	6年連続、通算9回目1

順位と継続年数がどちらも高い項目に共通するのは、被害が発生してからでは取り返しがつきにくいという点です。次に確認するのは、こうした脅威に対して、備えの側がどこまで追いついているかです。

3. 備えの側は、まだ追いついていません

ITリスク管理と業務継続計画の整備状況

IPAの調査によると、ITのリスク管理と業務継続計画を整備している企業は、全体の5〜6割程度です⁴。

残りの四〜五割の企業では、緊急時の対応の整備が済んでいません。案件を受ける側から見ると、委託元の備えがどちらに当たるかによって、求められる厳しさの水準が変わります。

事業継続計画が整った現場では、障害発生時の連絡経路や役割分担があらかじめ決まっており、担当する部分の輪郭がはっきりしています。整っていない現場では、その輪郭を自分から確認しにいく姿勢が必要になります。

DevOpsやモデルベース開発の導入

同じ調査では、DevOpsやモデルベース開発を導入している企業は、開発を請け負う側の企業を除くと少数にとどまります⁵。

開発を進める側の企業では一定の基盤が整っている一方、その基盤を使う側の企業には広がっていません。整備の差がある場所ほど、受ける側に求められる作業の幅が広がります。

委託元がどちらの状況に近いかによって、日々の進め方も変わります。基盤が整った現場では既存の仕組みに沿って進められますが、整っていない現場では、手順そのものを提案しながら進める場面が出てきます。

整備状況を並べて見ると

ITリスク管理・業務継続計画の整備状況と、DevOpsやモデルベース開発の導入状況を並べると、どちらも一定の企業には広がっているものの、全体には行き渡っていないという共通の姿が見えます。次の表は、この2つの項目を対象と状況で並べたものです。

項目	状況
ITリスク管理・業務継続計画の整備	全体の5〜6割程度が整備4
DevOps・モデルベース開発の導入	開発を請け負う側の企業を除くと少数5

整っている領域と、整っていない領域が混在している状況は、受ける側が自分の担当範囲をどこまで広げて考えるかという判断につながります。担当範囲を狭く捉えるより、周辺まで見渡す姿勢のほうが、結果として評価につながる場面があります。次に見るのは、部品そのものの把握という、もう一段具体的な備えの話です。

4. 部品の一覧が無いという前提で動いています

構成管理ツールの導入状況

構成管理のツールを導入している企業は、利用する側で約3割、開発を請け負う側で約4割にとどまります⁶。

どちらの立場でも、半数には届いていません。使っているソフトウェアの構成を、体系立てて把握できている現場は限られています。

構成管理が整っていない現場に入ると、最初にどんな部品がどのバージョンで動いているかを自分で確認する作業から始まることがあります。既存の仕組みをそのまま使える案件ばかりではないという前提を持っておくと、進め方の見立てがしやすくなります。

SBOMという部品の一覧

SBOM、つまりソフトウェアの部品表を導入している企業は1割未満です⁷。

部品の一覧を持たないまま運用している現場では、どこかに弱点が見つかったときに、影響がどこまで及ぶかを追いかける作業そのものが難しくなります。案件を受ける側には、この一覧を前提にしない現場を補う役回りが回ってきます。

参画してすぐに求められる作業として、使っている部品を洗い出して一覧にまとめる仕事が発生することがあります。過去に依存関係の整理や棚卸しに関わった経験があるなら、この場面でそのまま活かせる可能性があります。

把握の甘さが引き継がれます

構成管理ツールの導入割合は約3〜4割にとどまり⁶、部品表にあたるSBOMの導入は1割未満です⁷。部品を体系的に把握する仕組みそのものが、まだ広く行き渡っていません。

部品を把握する仕組みが薄い現場を引き継ぐ形で案件に入る以上、まず何が使われているかを確かめる作業が、最初の一歩になります。このやり取りは地味に見えても、後の設計判断すべての土台になります。次は、品質という言葉が現場でどう扱われているかを見ます。

出典：IPA「2024年度ソフトウェア動向調査 簡易分析レポート」（2025年4月）をもとに作成

5. 品質は最優先ですが、設計への取り組みは薄いままです

最優先とされる品質

同じ調査から、システムを利用する側の企業が、品質を最優先事項として捉えていると分かります⁸。

発注する側にとって、動くかどうかより先に、壊れないかどうかが判断の軸になっているということです。品質という言葉の重みが、他の項目より一段高い位置にあります。

この姿勢は、レビューの観点にも表れます。機能が仕様どおりに動くかという確認に加えて、想定外の入力や負荷が来たときにどう振る舞うかまで問われる場面が増えています。

設計への取り組みは薄いままです

一方で、モジュール性やデータモデルを意識した設計に取り組む企業は、利用する側の企業を中心に、依然として少数です⁹。

品質を最優先事項として捉える姿勢と、設計そのものに取り組む姿勢の間には、隔たりが残っています。求める水準に対して、実際に手を動かせる体制が追いついていないという状況です。

この隔たりは、参画する側にとって関わり方の幅として現れます。動く状態を保つだけでなく、モジュールの区切り方やデータの持ち方まで踏み込んで提案できると、任される範囲が広がる場面があります。

優先順位と実態を並べて見ると

品質を最優先事項として捉える姿勢と、設計に取り組む企業の少なさを並べると、求めるものと実際に投じられる体制の間にずれがあると見えてきます。次の表は、この2つの項目を姿勢と実態で並べたものです。

項目	実態
品質への姿勢	利用する側の企業が最優先事項として捉える8
設計への取り組み	モジュール性やデータモデルを意識した設計は依然として少数9

品質を求める声の大きさと、設計に投じられる体制の薄さが両立している状況では、受ける側の設計判断が、そのまま品質の実質を左右します。求められる基準を満たすかどうかは、最終的にこの判断の積み重ねで決まります。次に見るのは、こうした状況を踏まえたリスクの見方です。

6. リスクの見方には、手順があります

被害の大きさと発生の可能性で分析します

IPAの「脆弱性対処に向けた製品開発者向けガイド」では、脆弱性によって生じる被害とその大きさ、そして発生の可能性からリスクを分析すると示されています¹⁰。

危ないかどうかを感覚で判断するのではなく、被害の大きさと発生の可能性という2つの軸で位置づける手順です。同じ弱点でも、置かれている場所によって扱いが変わります。目立つ場所にある小さな弱点と、目立たない場所にある大きな弱点を、同じ物差しで比べられるようにする考え方です。

この手順を自分の言葉で説明できると、委託元との協議で優先順位を合わせやすくなります。すべての弱点に同じ重さで対応するのではなく、どこから手をつけるかを一緒に決められる関係が作れます。

備えの薄さと組み合わせて考えます

この手順を、備えの側がまだ追いついていない状況⁴と重ねると、見え方が変わります。委託元の備えが薄い案件ほど、被害が広がったときの影響を大きく見積もっておく意味が出てきます。

受ける側がこの手順を知っているかどうかは、設計の初期段階から効いてきます。後から手順を当てはめるのではなく、最初から被害の大きさを意識して設計する姿勢が、案件全体の評価につながります。

手順を自分の判断軸にします

リスクを分析する手順は、委託元から示されるものであると同時に、受ける側が自分の判断軸として持っておける考え方でもあります。同じ言葉を共有できることが、協議を進めやすくします。

設計の初期段階で、被害の大きさと発生の可能性をどう見積もったかを資料に残しておくと、後から委託元と話がずれたときに立ち戻る場所になります。口頭のやり取りだけで済ませないことが、日々の進め方の違いにつながります。記録を残す習慣は、次の案件で経験を語るときの材料にもなります。

この手順を踏まえたうえで、最後に確認したいのは、案件を受ける前にどの順番で厳しさを確かめておくかという点です。

出典：IPA「脆弱性対処に向けた製品開発者向けガイド」（2026年3月）をもとに作成

7. 求められる厳しさを、受ける前に確かめる順番

何を、どの順番で確かめるか

ここまでの内容を踏まえると、案件を受ける前に確かめておきたいことは、大きく2つに整理できます。1つは、その案件がどれだけ壊れたときの損害が大きい場所に位置しているかという点です¹。抽象的な印象で判断せず、具体的な言葉として確かめておくことが出発点になります。

もう1つは、被害の大きさと発生の可能性からリスクを分析する手順が、案件の中でどこまで求められているかという点です¹⁰。この2つを先に確かめておくと、参画してから戸惑う場面を減らせます。

この2つは、順番に確かめることに意味があります。損害の大きさを先に把握しておけば、リスク分析の手順がどこまで求められるかという次の問いにも、見当をつけた状態で臨めます。

確かめる材料は案件情報の中にあります

案件の条件や求められる経験の欄には、こうした厳しさの水準を映す言葉が含まれていることがあります。報酬や稼働条件だけでなく、こうした言葉にも目を向けると、案件の性格がより具体的に見えてきます。

面談では、過去にどんな障害を経験し、どう対処したかを尋ねられる場面が多くなります。うまくいった話だけでなく、うまくいかなかった経験をどう振り返り、次にどう活かしたかを言葉にしておくと、話が具体的に進みやすくなります。

Remoguが扱う案件は、90%以上がフルリモート可能です。厳しさの高い案件でも、稼働の場所にとらわれずに参画先を探せる可能性があります。ここまで整理した2つの確認事項は、案件を検索する段階から使える判断材料になります。

図の作成：Remogu編集部。ここまでの内容を整理したもので、統計データではありません

Rustの経験がまだ少なくても案件はありますか

経験がまだ少ない状態でも、案件の幅がまったく無いわけではありません。求められる厳しさの水準は案件によって異なるため、比較的水準の近い領域から関わりを持つという進め方もあります。まずは自分の経験と、案件が求める水準の距離を確かめることが出発点になります。過去に扱った規模や、障害対応の経験を具体的に振り返っておくと、面談で話す材料が整理しやすくなります。

案件ごとの厳しさの違いは何で見分けられますか

見分ける手がかりは、案件が扱う対象がどれだけ壊れたときの影響が大きいかという点と、委託元がどこまで備えているかという点です。10大脅威で上位に挙がる領域²ほど、求められる水準は高くなる傾向があります。案件情報や面談の中でこの2点を具体的に確かめておくと、参画後の認識のずれを防ぎやすくなります。備えが薄い現場ほど、設計の初期段階から関わる余地が大きいという見方もできます。

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

出典・参考情報

＊1 IPA「情報セキュリティ10大脅威 2026」直せる穴（2026年1月・2026年8月確認）
＊2 IPA「情報セキュリティ10大脅威 2026」1位の脅威（2026年1月・2026年8月確認）
＊3 IPA「情報セキュリティ10大脅威 2026」委託先という経路（2026年1月・2026年8月確認）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」止まる備え（2025年4月・2026年8月確認）
＊5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」確認の自動化（2025年4月・2026年8月確認）
＊6 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」構成の把握（2025年4月・2026年8月確認）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」部品の一覧（2025年4月・2026年8月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」評価の軸（2025年4月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」境界の不在（2025年4月・2026年8月確認）
＊10 IPA「脆弱性対処に向けた製品開発者向けガイド」優先順位（2026年3月・2026年8月確認）