Objective-Cで書かれたアプリの保守を打診されるケースが増えています。Swiftへの全面的な置き換えではなく、今動いているコードを保守として引き継ぐ依頼が中心です。引き受けるかどうかを分けるのは、書けるか書けないかではなく、壊れたときに何を負うかという点です。何を使っているかの一覧があるか、弱点の情報を誰が追うか、直せる体制があるかという3つの材料をそろえてから、返事をしたいところです。

1. 引き受けるかは壊れたときに何を負うかで決まる

書けるかではなく、壊れたときに何を負うかで判断する

Objective-Cという言語自体は、書こうと思えば書けます。ここで問われているのは技術の可否ではありません。今動いているアプリが壊れたとき、原因を突き止められるか、直す範囲を見きわめられるか、直した後の影響を確認できるかという、保守そのものの実行力です。

保守を引き受けるということは、コードを読むだけでなく、そのアプリが抱えているリスクを一時的に背負うということでもあります。何が起きても自分の責任にならない保守はありません。だからこそ、引き受ける前に負うものの正体を具体的にしておきたいところです。

その正体を具体的にする材料は3つあります。何を使っているかの一覧があるか、弱点の情報を誰が追うか、直せる体制があるかです。この3つが揃っていない案件ほど、期間も範囲も後から膨らみやすくなります。下の図は、この3つの材料を並べたものです。

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

3つの材料をそろえてから返事をする

実際のところ、この一覧を最初から渡してもらえる案件はそれほど多くありません。IPAの調査では、構成管理のツールを導入している企業は利用する側で約3割、提供する側で約4割にとどまっています⁷。つまり、依頼する側にも一覧が無いまま保守の話が始まる場合があるということです。

依頼する側にとっても、この3つが曖昧なままでは、保守という言葉が実務として機能しません。壊れたときに誰が確認し、誰が判断し、どこまでを保守の範囲とするかが決まっていて初めて、双方が同じ前提で作業を進められます。打診を受けた段階でこの3点を尋ねることは、警戒ではなく、保守を成立させるための確認です。

逆に言えば、この3点さえ具体的になれば、Objective-Cという言語そのものへの不安は、判断の中心ではなくなります。古い言語で書かれているという事実よりも、何を負うかが明確かどうかのほうが、保守の見通しを左右します。

この記事では、一覧の有無、弱点情報の追い方、直せる体制という順番で、確かめ方を具体的に見ていきます。最後に、引き受ける前に確認しておきたい順番を1つの流れとしてまとめます。

次の章では、一覧がどれくらい整っているのかを、実際の数字とあわせて見ていきます。

2. 何を使っているかの一覧が無いという前提

多くの企業が、部品の一覧を持たないまま運用している

何を使っているかの一覧というと難しく聞こえますが、中身は単純です。アプリがどのライブラリやフレームワークを使っているか、その版がいくつかを一枚の文書にしたものです。これが無いと、弱点が見つかったときに、まず「自分たちが何を使っているか」を調べるところから始まります。

IPAの調査によると、構成管理のツールを導入している企業は、利用する側の企業で約3割、提供する側の企業で約4割にとどまっています⁷。さらに、SBOM（使っている部品の一覧）を導入している企業は1割未満です⁸。一覧が無い状態のほうが、むしろ標準に近いということになります。

この状況は、Objective-Cのアプリに限った話ではありません。ただし、保守として引き継ぐ側からすると、一覧が無い前提で見積りを立てる必要があるという点は変わりません。コードを読んで洗い出す作業を、保守の工程として明示しておきたいところです。

一覧の有無で、最初にすることが変わる

一覧があるかどうかは、保守を始めた直後の動き方に直接影響します。一覧がある案件では、使っている部品と版がすぐに分かるため、弱点情報が出たときの照らし合わせが速くなります。一覧が無い案件では、まずコードを読んで構成を洗い出す作業が、保守の最初の工程として加わります。下の表は、その違いを整理したものです。

状態	構成や部品の把握	保守を引き受けた直後に起きること
一覧がある案件	使っているライブラリや部品が文書で分かる	弱点情報が出たとき、対象かどうかをすぐに照らし合わせられる
一覧が無い案件	構成管理のツールを導入している企業は利用する側で約3割・提供する側で約4割にとどまり7、部品の一覧を導入している企業は1割未満です8	まずコードを読んで、何を使っているかを洗い出すところから始まる

下の図は、構成管理のツールと部品の一覧を持っている企業の割合を示したものです。

一覧が無い案件を引き受けるときは、洗い出しにかかる時間を保守の範囲に含めるかどうかを、依頼する側とあらかじめ確認しておきたいところです。範囲に含めないまま進めると、後から追加の作業として扱われるかどうかで、認識のずれが生じやすくなります。

一覧が無い案件を見積るときは、洗い出しにどれくらいの時間がかかりそうかを、保守を始める前の段階である程度見立てておきたいところです。実際に読み進めながら、その見立てを更新していく形でも構いません。

洗い出しの作業は、一度終えれば終わりというものでもありません。保守を続ける中で、新しく加わった部品も一覧に反映していく運用が、次の弱点への備えにつながります。

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

一覧の有無を確認したら、次に見ておきたいのは、弱点の情報を誰が追うかという点です。

3. 弱点の情報を誰が追うか

弱点（脆弱性）は、放っておくと重い順位に位置づけられている

ここでいう弱点（脆弱性）とは、ソフトウェアの作り方や設定に生じる、悪用されうる欠陥のことです。情報セキュリティ10大脅威2026では、この弱点を悪用した攻撃が4位に位置づけられており、6年連続で9回目の選出です¹。

古い言語で書かれたアプリほど、この弱点への対応が更新されないまま残っている場合があります。動いているという理由だけで、弱点の有無そのものが確認されずに時間が経つことも珍しくありません。

保守として引き継ぐアプリが古い言語で書かれているほど、この弱点への向き合い方が問われます。誰も追っていない弱点は、見つかったときにはすでに悪用されている場合もあります。

保守を引き受ける側が最初に確認したいのは、過去にどんな弱点が報告されたことがあるか、そのうち直っていないものが残っていないかという点です。この確認は、コードを書き換える前の作業として位置づけられます。

誰が、何を、どう追うかを決めておく

弱点への向き合い方は、依頼する側と引き受ける側で役割が違います。依頼する事業者は、被害の大きさと発生の可能性の両方からリスクを分析するという順番を示しています⁶。引き受ける側は、依頼された範囲の弱点情報を継続して追い、修正の要否を伝える役割を担います。どちらが何を追うのかを、保守を始める前にすり合わせておきたいところです。下の表は、その役割の違いをまとめたものです。

誰が	何を追うか	追わなかったときに起きること
依頼する事業者	被害の大きさと発生の可能性からのリスク分析6	優先順位を付けずに直す順番を決めてしまい、対応が後手に回る
保守を引き受ける側	依頼された範囲の弱点情報	弱点を悪用した攻撃は4位に位置づけられており1、見落とすと保守の範囲を超えた被害につながる

依頼する事業者と引き受ける側、どちらが弱点情報を追うかが決まっていない案件では、双方が「相手が見ているはず」と思い込んだまま時間が過ぎることがあります。担当を先に決めておくことが、この思い込みを防ぐ最初の一歩です。

弱点情報を追う担当が決まっている案件では、保守を引き受けた後も、新しく見つかった弱点についての連絡が定期的に届きます。担当が決まっていない案件では、この連絡自体が発生しないこともあります。

弱点情報の追い方が決まっている案件ほど、保守にかかる時間の見通しも立てやすくなります。急な対応が必要になったときも、誰が最初に動くかがあらかじめ分かっているためです。

弱点をどう追うかが決まったら、次に確かめたいのは、実際に直せる体制があるかどうかです。

4. 直せる体制があるか

OSSの方針や、部品を管理する担当が定まっていない

直せる体制とは、弱点が見つかったときに、誰がどの手順で修正して、どう展開するかが決まっている状態を指します。IPAの調査では、OSS（オープンソースソフトウェア）の方針や、それを管理する担当の部署（OSPO）が整っていない企業が多いことが分かっています⁹。

体制が整っていないと、修正そのものはできても、誰の確認で展開するか、どこまで確かめてから公開するかが、そのつど決め直しになります。保守の期間が読みにくくなる原因の一つです。

体制がある案件では、弱点が見つかってから展開するまでの手順があらかじめ言葉になっています。誰が確認し、誰が判断し、どのタイミングで反映するかが、保守を始める前から共有されています。

外部のサービスに任せる部分ほど、不安が残りやすい

アプリの一部を外部のサービスに任せている場合、その部分の保守や運用に不安を抱える企業が多いことも分かっています¹⁰。任せている範囲が見えにくいほど、この不安は残りやすくなります。

外部のサービスを使っている範囲を、保守の対象として明示してもらうことも確認の一つです。対象に含まれていない部分については、誰が見ているのかを依頼する側に確かめておきたいところです。

体制の有無は、契約の形にも表れます。誰が確認し、誰が展開するかが決まっている案件では、保守の範囲や進め方についての合意も具体的になりやすくなります。

反対に、体制が定まっていない案件では、保守を引き受けた後になって、確認や展開の手順を一から決めることになりがちです。引き受ける前に、この点を確かめておく価値があります。

つまり、直せる体制があるかを確かめるときは、依頼元の体制だけでなく、外部のサービスに任せている部分の体制も合わせて確認しておきたいところです。一覧があるかどうかは、この体制にも影響します。下の図は、一覧がある場合とない場合で、直す流れがどう変わるかを整理したものです。

図の作成：Remogu編集部。一覧がある場合とない場合で、直すまでの流れがどう変わるかを整理したもので、統計データではありません

体制まで確認できたら、次はどんな危険が実際に起きているのかを具体的に見ていきます。

5. 危険の中身を具体で見る

内部からの漏えいと、外部からの妨害

情報セキュリティ10大脅威2026には、保守に関わる危険がいくつも並びます。内部からの情報漏えいは7位で、11年連続11回目の選出です²。サービス妨害を狙う攻撃(DDoS攻撃)は9位で、2年連続7回目の選出です³。メールを装った詐欺(ビジネスメール詐欺)は10位で、9年連続9回目の選出です⁴。それぞれ何が起きるのかを、下の表で並べて確認します。

危険	順位(2026年)	何が起きるか
内部からの情報漏えい	7位2	保守に関わる担当者の権限を通じて、データが外に出る
サービス妨害を狙う攻撃(DDoS攻撃)	9位3	アプリやその周辺の仕組みが、外部からの通信で止められる
メールを装った詐欺(ビジネスメール詐欺)	10位4	保守の依頼や請求のやり取りを装って、金銭や情報を狙われる

これらの危険は、保守として引き継ぐアプリの外側でも起きます。取引先とのやり取り、社内の権限管理、外部からの通信経路など、アプリそのもの以外の部分が入り口になることも珍しくありません。

メールを装った詐欺は、保守の依頼そのものを装って近づいてくることもあります。実在する担当者の名前や、実際にありそうな請求のやり取りを模した内容のため、送信元の見た目だけでは判断しにくい場合があります。

3つの危険は、それぞれ別の入り口からやってきます。だからこそ、どれか一つに備えるのではなく、保守を始める段階で3つとも確認しておきたいところです。

3つの危険をあらかじめ知っておくことは、保守を怖がる材料ではありません。何に注意すればよいかが具体的になるほど、引き受けた後の対応も落ち着いて進められます。

順位の高さより、自分に関わる危険かどうかを見る

順位そのものより大事なのは、保守として引き継ぐアプリが、この3つのどれと関わりやすいかです。外部からの通信を受け付ける仕組みがあれば妨害を狙う攻撃に、担当者の入れ替わりが多ければ内部からの漏えいに、それぞれ注意が向きます。

内部からの情報漏えいは、保守に関わる人が増えるほど、確認しておきたい対象になります。誰がどの範囲の権限を持っているかを保守の開始時に整理しておくと、後から関わる人が増えたときにも対応しやすくなります。

サービス妨害を狙う攻撃は、アプリの規模に関わらず起こり得ます。古いアプリだから狙われにくいというわけではなく、外部からの通信を受け付ける仕組みがあるかどうかが、注意の向け方を決めます。

こうした危険は、古い言語で書かれたアプリに限った話ではありません。次の章では、新しく加わった危険についても見ていきます。

6. 新しい危険も入ってくる

AIの利用をめぐる危険が、初めて選出された

情報セキュリティ10大脅威2026では、AIの利用をめぐるサイバーリスクが初めて選出されました⁵。これまで無かった種類の危険が、保守の対象にも関わり始めているということです。

初めて選出されたということは、これまでの対策の型がそのまま当てはまるとは限らないということでもあります。保守の中でAIを使う場面が出てきたら、その使い方自体も確認の対象に加えておきたいところです。

古いアプリだからといって、新しい危険と無縁というわけではありません。保守の作業自体にAIを使う場面が増えるほど、この種類の危険にも注意が向きます。

保守として引き継ぐアプリに、AIを使った機能を新たに組み込む打診が来ることもあります。その場合は、組み込む範囲と、誰がその部分の弱点情報を追うかを、他の3つの材料と同じように確認しておきたいところです。

AIの利用をめぐる危険は、保守を依頼する側にも関係します。依頼する事業者がAIを使って要件をまとめる場合、その内容の確認も、保守を引き受ける側の役割に含まれることがあります。

新しい危険への向き合い方も、結局は3つの材料と同じところに戻ります。何を使っているか、誰が弱点情報を追うか、直せる体制があるかです。

外部に任せる部分の不安は、新しい危険にもつながる

アプリの一部を外部のサービスに任せている企業では、その保守や運用に不安を抱える企業が多いことも分かっています¹⁰。任せている部分が増えるほど、確認しておきたい対象も増えます。

確認する対象が増えると、一つひとつを個別に見るより、一覧に加えていく形にしたほうが管理しやすくなります。新しい危険が加わるたびに一覧を更新する運用そのものが、直せる体制の一部になります。

新しい危険が加わるたびに一覧を作り直すのではなく、確認する仕組みそのものを保守の体制に組み込んでおきたいところです。

Remoguは、案件の90%以上がフルリモート可能な、リモート案件に特化したエンジニアマッチングです。今の経験を活かしながら、次に引き受ける案件の条件を確かめてみることができます。

7. 引き受ける前に確かめる順番

3つの材料を、確認できる順番に並べる

ここまで見てきた3つの材料と、危険の中身をふまえると、確認する順番が見えてきます。まず一覧の有無を確認し、次に弱点情報を誰が追うかを確認し、続いて直せる体制を確認します。そのうえで、被害の大きさと発生の可能性からリスクを分析するという考え方⁶に沿って優先順位の付け方を確認し、最後に条件を協議します。下の図は、この順番を整理したものです。

図の作成：Remogu編集部。確認しておきたい順番を整理したもので、統計データではありません

この順番を踏むことで、断る場合も、条件を付けて引き受ける場合も、判断の理由を具体的に説明できるようになります。感覚での可否ではなく、確認した事実にもとづく返事になります。

確かめてから返事をすれば、期間も範囲も見えてくる

一覧が無いまま保守を引き受けると、構成管理のツールを導入している企業が利用する側で約3割、提供する側で約4割にとどまる⁷という状況と同じ立場に、自分も立つことになります。だからこそ、確認する順番を先に決めておく意味があります。

ここからは、Objective-Cの保守を引き受けるときによく挙がる疑問について、順番に見ていきます。

Objective-Cの経験しかなくても、保守の打診を受けて良いのでしょうか

言語の経験だけでなく、壊れたときに何を負うかを先に確認できれば、判断の材料になります。一覧の有無、弱点情報の追い方、直せる体制の3つを確認してから返事をすれば、経験の有無だけで判断するより具体的に検討できます。

SwiftとObjective-Cが混在するアプリでも、保守として引き受けられますか

混在しているアプリ自体は珍しくありません。ここでも判断の軸は同じで、混在している部分も含めて一覧があるか、弱点情報を誰が追うかが決まっているかを確認しておきたいところです。

保守の範囲が曖昧な打診には、どう返信すればよいですか

範囲が曖昧なまま引き受けると、直す範囲も期間も後から膨らみやすくなります。一覧の有無と直せる体制を先に確認しておきたいと伝えることが、そのまま最初の一歩になります。

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

出典・参考情報

＊1 IPA「情報セキュリティ10大脅威 2026」直せる穴（2026年1月・2026年8月確認）
＊2 IPA「情報セキュリティ10大脅威 2026」内側の経路（2026年1月・2026年8月確認）
＊3 IPA「情報セキュリティ10大脅威 2026」止められる攻撃（2026年1月・2026年8月確認）
＊4 IPA「情報セキュリティ10大脅威 2026」人を狙う手口（2026年1月・2026年8月確認）
＊5 IPA「情報セキュリティ10大脅威 2026」新しい脅威（2026年1月・2026年8月確認）
＊6 IPA「脆弱性対処に向けた製品開発者向けガイド」優先順位（2026年3月・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「2024年度ソフトウェア動向調査 簡易分析レポート」不安の所在（2025年4月・2026年8月確認）