クラウドの活用やリリース頻度の高まりで、開発のスピードは上がった一方、セキュリティを後工程やセキュリティ部門任せにしたままでは、公開するWebサービスや社内システムを守りきれない場面が増えています。「DevOpsは回しているが、最近よく聞くDevSecOpsとは何が違うのか。うちがやっていることと別物なのか」と気になって調べ始めた方も多いはずです。
DevSecOpsは、セキュリティ（Security）が名前に足されただけなのでしょうか。それとも、セキュリティを「いつ・誰が・どう」扱うかという、工程・担当・文化のレベルまで変わる話なのでしょうか。違いの大きさがつかめないと、自社で何を変えればよいのかも描けません。
本記事では、DevOpsとDevSecOpsの違いを定義の対比と比較表で整理したうえで、シフトレフト（セキュリティの前倒し）・責任分担・文化の違い、SAST・DAST・SCA・IASTといった検査手法の役割と開発工程への組み込み方、そしてDevSecOpsを実現するための具体的な次の一歩までを解説します。自社の現状と照らし合わせ、どこから着手するかを判断する材料としてご活用ください。
目次
一括ダウンロードする
DevOpsとDevSecOpsの違いとは｜定義の対比と比較表
まず結論から、両者の定義を一行ずつ対比します。DevOpsは、開発（Development）と運用（Operations）を連携させ、リリースを速く・継続的に行う開発の進め方です。DevSecOpsは、その流れにセキュリティ（Security）を組み込み、開発スピードを保ちながらセキュリティも確保しようとする体制・手法を指します。
DevSecOpsについて、デジタル庁はガイドラインの用語定義で次のように説明しています。
開発と運用がシームレスに連携する DevOps にセキュリティを組み込むことで、セキュリティを確保しつつ、開発スピードを損なわない開発の体制や手法
出典：政府情報システムにおけるセキュリティ・バイ・デザインガイドライン（表1-1 用語の定義）｜デジタル庁
この定義からわかるのは、DevSecOpsは「DevOpsにセキュリティを足したもの」でありながら、足し方が後付けではないという点です。開発の速さを落とさずにセキュリティを確保するために、セキュリティを扱うタイミング・担当・目的そのものを見直します。両者の違いを観点別に並べると、次のように整理できます。
| 比較の観点 | DevOps | DevSecOps |
|---|---|---|
| セキュリティを扱うタイミング | 開発・リリースの後工程、または専門チームへの依頼時にまとめて対応しやすい | 企画・設計・実装・テストの各工程に検査を組み込み、早い段階から継続的に対応（シフトレフト） |
| 担当・責任 | 開発チームと運用チームが中心。セキュリティは専門チームに分かれがち | 開発・運用・セキュリティの三者が連携し、開発者を含む全員で責任を共有 |
| 主な目的 | 開発と運用の連携による、速く継続的なリリース | 開発スピードを保ちながら、セキュリティも同時に確保 |
| 開発工程での扱い | 機能開発を優先し、セキュリティ検査は終盤に寄りやすい | 各工程にセキュリティ作業を割り当て、自動化で継続的に検査 |
| 代表的な手法・ツール | CI/CD、構成管理、監視 | CI/CDにSAST・DAST・SCAなどの検査を統合 |
※上記は一般的な傾向の整理です。実際の体制やツール構成は組織・プロジェクトにより異なります。
DevSecOpsという言葉には、唯一の厳密な定義が業界で定まっているわけではありません。米国国立標準技術研究所（NIST）も、この用語にコミュニティ全体の合意があるわけではないと述べたうえで、DevSecOpsを「文化と一連の実践、および自動化ツールによって、開発・運用・セキュリティの関係者間の協働や責任共有を進めるもの」と位置づけています。
このように、特定の製品を入れれば完成するものではなく、進め方と体制を変える取り組みだと捉えると、違いが理解しやすくなります。
DevSecOpsで何が変わるのか｜タイミング・責任・文化の違い
ここからは、違いの中身を具体的に見ていきます。DevSecOpsで変わるのは、大きく「セキュリティを入れるタイミング」「責任の持ち方」「組織の文化」の3つです。いずれも、製品を導入するだけでは実現しない、進め方の変化です。
セキュリティを入れるタイミングの違い（シフトレフト）
最も大きな違いが、セキュリティ対策を行うタイミングです。従来は、開発を終えてリリース直前に脆弱性診断を行う、あるいは運用に入ってから問題が見つかって対応する、という流れになりがちでした。この場合、見つかった脆弱性を直すために設計や実装まで戻ることになり、手戻りが大きくなります。
DevSecOpsでは、セキュリティの検査を開発の前工程へ前倒しします。これを「シフトレフト」と呼びます。開発の流れを左から右に並べたとき、右側（後工程）で行っていた対策を左側（前工程）へ移す、という意味です。
OWASPのDevSecOps Guidelineも、セキュアなパイプラインに検査ツールを組み込み、開発プロセスにシフトレフトのセキュリティ文化を広めること、そして「セキュリティの問題をできるだけ早く検知する」ことを目標に掲げています。
企画・設計の段階からセキュリティを織り込む考え方は、公的なガイドラインでも示されています。デジタル庁は、企画工程からセキュリティを実装する「セキュリティ・バイ・デザイン」の必要性が高まっているとし、ソフトウェア開発における同様の方策をDevSecOpsと呼ぶと説明しています。
一般的に、開発から運用まで含めたシステム開発ライフサイクル全体でセキュリティ確保する方策を（とりわけソフトウェア開発においては）DevSecOps と呼ぶが、本書では政府情報システムの企画工程から設計工程、開発工程、運用工程まで含めた全てのシステム開発ライフサイクルにおいて、一貫したセキュリティを確保する方策のことを「セキュリティ・バイ・デザイン」と定義する。
出典：政府情報システムにおけるセキュリティ・バイ・デザインガイドライン（2.1 セキュリティ・バイ・デザインの概要）｜デジタル庁
前倒しの具体像は、工程ごとに検査を差し込むことです。たとえば実装中にソースコードを自動で解析し、依存しているライブラリに既知の脆弱性がないかを継続的に確認します。早く見つけるほど修正は小さく済み、継続的なリリースを止めずに安全性を保てます。
責任の持ち方の違い（専門チーム任せから全員で共有へ）
2つ目の違いは、セキュリティの責任を誰が持つかです。DevOpsでは、開発と運用が連携する一方、セキュリティは専門チームが別で担当する構図になりやすく、「セキュリティは最後に専門部署が見るもの」という前提が残りがちでした。
DevSecOpsでは、開発・運用・セキュリティの三者が連携し、開発者を含む全員がセキュリティの責任を分け合います。NISTも、DevSecOpsという用語は、セキュリティチームの役割をプロセス全体のなかで強調するために使われるようになったと述べています。
開発者が自分の書くコードの安全性に関わり、セキュリティ担当は開発の早い段階から関与する——この責任の共有が、後工程での押し付け合いや手戻りを減らします。
組織文化・体制の変化
3つ目は、組織の文化と体制です。タイミングと責任を変えるには、ツールを入れるだけでは足りず、チーム間の関係や評価の仕方まで見直す必要があります。開発・運用・セキュリティがそれぞれの要件を理解し合い、セキュリティを「自分ごと」として扱える状態をつくることが、DevSecOpsの土台になります。
この文化づくりは一度で完成するものではありません。小さな範囲から検査の自動化を始め、見つかった問題をチームで共有して改善する、という運用を繰り返しながら、徐々に浸透させていくのが現実的な進め方です。
DevSecOpsが注目される背景｜なぜ今セキュリティを前倒すのか
なぜ今、セキュリティの前倒しが求められているのでしょうか。背景には、攻撃の対象と手口の変化があります。情報処理推進機構（IPA）の「情報セキュリティ10大脅威 2025」では、組織向けの脅威として「サプライチェーンや委託先を狙った攻撃」が2位、「システムの脆弱性を突いた攻撃」が3位に挙げられています。
サプライチェーンを狙う攻撃には、ソフトウェアが利用するオープンソースや外部ライブラリの脆弱性を突く手口が含まれます。自社で書いたコードだけでなく、取り込んでいる部品まで安全性を確認しなければ守りきれない、という状況です。開発のスピードが上がり、外部の部品を数多く組み合わせて作るようになったほど、脆弱性が入り込む経路は増えます。
こうした脅威に、リリース直前の一度きりの検査で対応するのは難しくなっています。開発の各工程に検査を組み込み、継続的に脆弱性を洗い出す——DevSecOpsが注目されるのは、この継続的なセキュリティ確保が現実的な解になってきたためです。
この変化は、脅威の側だけでなく開発のあり方の側からも起きています。AIの活用で開発のスピードがさらに上がったぶん、リリースのたび・アップデートのたびに、より短いサイクルでセキュリティを確認したいという必要性が高まっています。
一括ダウンロードする
DevSecOpsをどう実現するか｜検査ツールの役割と開発工程への組み込み
違いを押さえたうえで、ここからは「ではどう実現するか」という実装の話に進みます。DevSecOpsの実現は、セキュリティ検査のツールを用意し、それを開発工程のどこに挟むかを決めることから始まります。まず各検査手法が「何を・どの工程で」見るものかを整理し、次にそれを工程の流れに落とし込みます。
セキュリティ検査ツールの役割（SAST・DAST・SCA・IAST）
DevSecOpsでよく使われる検査手法には、主にSAST・DAST・SCA・IASTの4つがあります。名前だけ見ると似ていますが、何を・どの状態で検査するかが異なります。NIST SP 800-204Cは、調査会社ガートナーの分類を引く形で、これら4つのアプリケーションセキュリティテスト（AST）手法を次のように整理しています。
| 検査手法 | SAST（静的解析） | SCA（ソフトウェア構成分析） | DAST（動的解析） | IAST（対話型解析） |
|---|---|---|---|---|
| 何を見るか | ソースコード・バイトコード・バイナリを実行せずに解析し、脆弱性を検出 | 利用中のオープンソース・外部部品と、その既知の脆弱性やライセンスの制約を特定 | 稼働中のアプリに外部から疑似的な攻撃を行い、反応から脆弱性を検出 | DASTに、テスト対象の実行環境内に検査用のしくみを組み込む方式（計装）を組み合わせて検出 |
| 主な工程 | 実装〜テスト | 実装〜運用 | テスト〜運用 | テスト |
| 代表例 | SonarQube など | GitLab Dependency Scanning など | OWASP ZAP など | Contrast Assess など |
※手法の定義はNIST SP 800-204C（ガートナーの分類を引用）に基づく整理で、主な工程は一般的な開発・CI/CD工程への割り当てです。代表例は各手法の一例で、優劣を示すものではありません。
ごく単純化すると、SASTとSCAは「作っているコードと部品」を早い段階で見る手法、DASTとIASTは「動かしたアプリ」をテスト以降で見る手法です。一方だけでは守る範囲が偏るため、工程に合わせて組み合わせるのが基本になります。
開発工程のどこにセキュリティを組み込むか
次に、これらの検査を開発の流れに落とし込みます。要件定義から設計、実装、テスト、リリース・運用までの各工程に、セキュリティの作業を割り当てていくのがDevSecOpsの進め方です。公的なガイドラインでも、工程ごとにセキュリティ作業を対応づける整理が示されています。
一般的な開発工程に当てはめると、前節で整理した検査手法は次のように各工程へ組み込まれます。
| 工程 | 要件定義・設計 | 実装 | テスト | リリース・運用 |
|---|---|---|---|---|
| 主なセキュリティ作業 | 想定される脅威を洗い出し、セキュリティ要件を決める（脅威モデリング） | 書いたコードと取り込んだ部品の脆弱性を継続的に検査 | 動かした状態のアプリに疑似攻撃を行い、実行時の脆弱性を確認 | 公開後も監視し、新たに公表された脆弱性や攻撃の兆候を検知して対応 |
| 対応する検査 | 設計レビュー中心（自動検査の前段） | SAST・SCA | DAST・IAST | 監視（＋定期的な脆弱性診断） |
デジタル庁のガイドラインでも、システム開発の各工程にセキュリティ作業が割り当てられており、テスト工程には「セキュリティテスト」として脆弱性診断が明記されています。自動化できる検査はCI/CDのパイプラインに組み込んで継続的に回し、専門的な判断が必要な検査は外部の脆弱性診断サービスに委ねます。この組み合わせが、多くの企業にとって現実的な実装の形になります。
DevSecOps導入のメリットと課題
DevSecOpsを取り入れると何が得られ、何につまずきやすいのかを整理します。導入を検討する際の判断材料としてご覧ください。
メリット
主なメリットは次の3点です。いずれも、セキュリティを前倒しし、継続的に検査することから生まれます。
- 手戻りとコストの削減：脆弱性を早い工程で見つけられるため、リリース直前や公開後に設計まで戻る大きな手戻りを避けられます
- 脆弱性への迅速な対応：検査を自動化してCI/CDに組み込むことで、新たに見つかった脆弱性にも継続的に対応しやすくなります
- チーム全体のセキュリティ意識の向上：開発・運用・セキュリティが責任を共有することで、セキュリティが一部門の仕事から全員の関心事に変わります
課題・つまずきやすい点
一方で、導入にあたっては次のような課題もあります。進め方を誤ると、ツールだけが増えて形骸化しかねません。
- ツール導入・運用のコストと手間：SAST・DAST・SCAなど複数の検査を組み合わせるため、導入や連携の設定、検出結果の対応に工数がかかります
- 組織文化の変革：役割分担や評価が定着した組織ほど、責任を共有する文化への移行に時間と合意形成が必要です
- 検査結果の取捨選択：ツールを増やすほど検出結果（アラート）も増えます。何を優先して直すかを判断し、誤検知を絞り込む運用がないと、対応に追われてしまいます
これらの課題は、一度に全工程へ広げようとせず、効果の大きい検査から小さく始めて段階的に広げることで和らげられます。自社に専門人材がいない場合は、検査の一部を外部のサービスに委ねる選択も現実的です。
現状のDevOpsから何を始めるか｜DevSecOpsを実現する次の一歩
最後に、現状のDevOpsからDevSecOpsへ進むための、最初の一歩を考えます。前述のとおり、実装の中心は「セキュリティ検査を開発工程に組み込み、継続的に回す」ことです。
まず自分たちで始めるなら、いきなり全工程へ広げず、既存のCI/CDに最初の一手としてSCA（依存ライブラリの検査）やSASTを組み込み、検出された脆弱性に対応する流れを小さく回すところからが現実的です。手を付けやすく効果も見えやすいため、社内の合意形成も進めやすくなります。
そのうえで、自前では手の回らない範囲や、専門的な判断が必要な検査を、ツールや外部の診断サービスで補います。自社の状況に応じて、次の2つの方向が着手しやすい入口になります。
- 開発パイプラインに検査を自分たちで組み込みたい場合は、依存ライブラリやソースコードの検査を開発工程に組み込める検査ツール（SaaS）から始める
- 専門的な判断や継続的な診断を外部に任せたい場合は、ソースコード診断を含む脆弱性診断サービスを定期的に利用する
ここでは、この2つの入口に当てはまる具体的なサービスを紹介します。自社がどちらの進め方に近いかを考えながら、比較の材料としてご覧ください。
| サービス名 | Aikido Security | CoWorker 脆弱性診断サービス |
|---|---|---|
| 提供形態 | 検査ツール（SaaS） 自動スキャンを自社で運用 | 脆弱性診断サービス AI解析と専門家レビューによる受託診断 |
| 主な検査 | SAST（ソースコード） SCA（依存ライブラリ） DAST・CSPM（クラウド設定）を オールインワンで検査 | ソースコード診断（静的） 動的診断（Web/API） ペネトレーションテスト |
| 開発工程への組み込み方 | エディター拡張やCI/CDパイプラインに組み込み、日常の開発工程で継続的に検査。修正案のプルリクエストを自動作成（オートフィックス） | リリース前や定期的に外部へ診断を依頼。年1回から四半期・月1回などの頻度に対応 |
| 料金の目安 | 年額サブスクリプション型 日本窓口（AndGo）参考価格で月額5万円台〜（年3,780ドル・利用者10人・年間契約時） 無料で試せるプランあり（2026年11月時点） | ソースコード診断15万円〜 動的診断30万円〜（APIエンドポイント数に応じる） Webペネトレーションテスト60万円〜（2026年10月時点） |
| 向いているケース | 開発チーム自身が検査を日々の工程に組み込みたい場合 | 検査の専門的な判断を外部に委ねたい場合 |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
※料金は各社の公表時点（Aikido Securityは2026年11月、CoWorkerは2026年10月時点）の参考価格です。利用規模や診断対象により変動するため、最新の金額・適用条件は各社の資料・見積りでご確認ください。
1. Aikido Security｜オールインワン脆弱性診断SaaS（株式会社AndGo）
ソースコード、依存ライブラリ、クラウド設定、コンテナ、稼働中のWebアプリまでを1つの管理画面で検査するSaaSです。日本では株式会社AndGoが販売・問い合わせ窓口を務めています。
SAST（ソースコード）・SCA（依存ライブラリ）・DAST・CSPM（クラウド設定）といった複数の検査を分断せずにまとめて扱える点が特徴で、前述したDevSecOpsの「検査を開発工程に組み込む」実装に素直に当てはまります。
検出した脆弱性について、修正案のドラフトを作ってプルリクエストまで自動で作成する機能（オートフィックス）を備え、エディターの拡張やCI/CDパイプラインへの組み込みにも対応します。検査して終わりではなく、直すところまで進めやすい設計です。
料金は年額のサブスクリプション型で、日本窓口のAndGoの参考価格では月額5万円台から（利用者10人・年間契約時）、利用人数に応じたプランが用意されています。無料で試せるプランもあります（料金は要確認・2026年11月時点）。開発チーム自身が検査を日々の工程に組み込みたい場合の入口になります。
こうしたツールが求められる背景について、提供元である株式会社AndGoの原氏は、開発現場でのセキュリティの位置づけの変化を次のように語っています。
正直なところ、昔は「セキュリティは運用側が最後に何とかするもの」という前提が強かったと思います。ですが今は攻撃の手口も複雑ですし、作ったあとに1回チェックして終わり、では追いつきません。だから開発の初期からセキュリティを組み込むDevSecOps（開発（Dev）、セキュリティ（Sec）、運用（Ops））が現実解になってきていて、Aikido Securityはその“回し方”を作るためのツールだと考えています。
2. CoWorker 脆弱性診断サービス（CoWorker株式会社）
CoWorker株式会社が提供する、Webアプリケーションやシステムを対象とした脆弱性診断サービスです。診断メニューは目的に応じて3種類から選べます。ソースコードを読み取って脆弱性を確認する静的診断、稼働中のアプリにアクセスして解析する動的診断、仮想的な攻撃で影響範囲を評価するペネトレーションテストです。
料金は、ソースコード診断が15万円から、動的診断がAPIのエンドポイント数に応じて30万円から、Webペネトレーションテストが60万円からという設定です（2026年10月時点）。
自社開発のAI「Red Agent」による解析と社内の専門家による確認を組み合わせており、年1回・リリース直後だけの診断から、より高頻度の定期的な診断へ移行したい場合の選択肢になります。検査の専門的な判断を外部に委ねたい企業に向いています。
年1回の診断では追いつかなくなってきた背景について、CoWorker株式会社の一ノ瀬氏は次のように説明します。
一方で、攻撃者側もAIを活用するようになり、新しく、しかもスピード感の早い攻撃が増えてきています。これまでは年に1回、あるいはサービスをリリースした直後にだけ脆弱性診断を行うという企業が多かったのですが、AIの発達によって攻撃側のスピードが上がっている以上、定期的に診断をしないと危険だという状況になってきました。
ここで取り上げた2つのサービスは、あくまで着手しやすい入口の例です。脆弱性診断サービスは診断方法・費用・対応範囲が各社で異なるため、ほかの選択肢も含めて全体を見比べたい場合は、以下の記事で診断方法・費用相場・選び方を解説しています。
脆弱性診断サービスおすすめ比較｜診断方法・費用相場・選び方を解説【無料ツールあり】
Webサービスや社内システムの脆弱性診断を検討する際、「専門家による手動診断とツールによる自動診断のどちらが自社に必要なのか」「費用が数十万円から数百万円までと幅が広く、妥当な予算が読めない」といった壁に突き当たる担当者は少なくありません。…
まとめ
DevOpsとDevSecOpsの違いは、「セキュリティが足されただけ」ではなく、セキュリティを扱うタイミング・責任・文化が変わる点にあります。後工程や専門チーム任せだったセキュリティを、企画・実装・テストの各工程へ前倒しし（シフトレフト）、開発者を含む全員で責任を共有する——これがDevSecOpsの中心です。
実現の鍵は、SAST・DAST・SCA・IASTといった検査を開発工程のどこに組み込むかを決め、自動化できるものはパイプラインに、専門的な判断が要るものは外部の診断サービスに委ねることです。
現状のDevOpsから始めるなら、依存ライブラリやソースコードの検査を工程に組み込めるツール、あるいはソースコード診断を含む脆弱性診断サービスから着手するのが現実的です。自社の体制と優先度に合わせて、まずは資料を取り寄せて比較検討を進めてください。
一括ダウンロードする
よくある質問（FAQ）
Q. DevSecOpsとDevOpsの違いは何ですか？
A. DevOpsとDevSecOpsの違いは、セキュリティを「いつ・誰が・どう」扱うか、つまりタイミング・責任・文化が変わる点にあります。DevOpsではセキュリティを後工程や専門チームに任せがちですが、DevSecOpsでは企画・設計・実装・テストの各工程に検査を前倒しで組み込み（シフトレフト）、開発者を含む全員で責任を共有します。
「Security（セキュリティ）が名前に足されただけ」ではなく、開発の進め方そのものが変わります。
Q. DevSecOpsのシフトレフトとは何ですか？
A. シフトレフトとは、従来は開発の後工程で行っていたセキュリティ検査を、企画・設計・実装といった前工程へ前倒しする考え方です。開発の流れを左から右に並べたとき、右側（後工程）の対策を左側（前工程）へ移すことからこう呼ばれます。脆弱性を早い段階で見つけるほど修正は小さく済み、継続的なリリースを止めずに安全性を保てるため、DevSecOpsの中心となる考え方です。
Q. SAST・DAST・SCA・IASTはどう使い分けますか？
A. 大きく分けると、SASTとSCAは「作っているコードと部品」を実装の早い段階で、DASTとIASTは「動かしたアプリ」をテスト以降で検査する手法です。SASTはソースコードを実行せずに解析し、SCAは取り込んだオープンソースや外部ライブラリの既知の脆弱性を特定します。
DASTは稼働中のアプリに疑似攻撃を行い、IASTはそれに実行環境内のエージェントを組み合わせて検出します。一方だけでは守る範囲が偏るため、工程に合わせて組み合わせるのが基本です。
Q. DevSecOpsを導入すると開発スピードは落ちますか？
A. DevSecOpsは、セキュリティ検査を自動化して開発工程に組み込むことで、スピードを保ちながら安全性を確保することを目的とした手法です。検査を後工程にまとめると、脆弱性が見つかるたびに設計まで戻る大きな手戻りが発生します。
前倒しで小さく継続的に検査すれば、かえって手戻りが減り、リリースを止めずに進めやすくなります。ツールを増やしすぎて検出結果の対応に追われないよう、効果の大きい検査から始めることがスピード維持の鍵になります。
Q. DevSecOpsは何から始めればよいですか？
A. DevSecOpsは、効果の大きい検査から小さく始め、段階的に広げていくのが現実的です。一度に全工程へ広げようとせず、まずは実装工程で依存ライブラリやソースコードの検査を自動化するなど、着手しやすいところから始めます。
自社に専門人材がいない場合は、検査の一部を外部の脆弱性診断サービスに委ねる方法もあり、自動化できる検査と専門家に任せる検査を組み合わせるのが多くの企業にとって現実的な進め方です。
DevSecOpsに役立つ脆弱性診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、ソースコードや依存ライブラリの検査を開発工程に組み込める診断ツールや、ソースコード診断を含む脆弱性診断サービスの最新資料を無料で一括請求できます。機能・料金・対応範囲を並べて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
