アルゴリズム / 計算複雑性理論（computational complexity theory） / P / NP

用語集

アルゴリズム / 計算複雑性理論（computational complexity theory） / P / NP

データ活用やDX成功に必要な考え方を、各種キーワードの解説で理解できる用語解説集です。
今回は、コンピュータプログラムの性能や暗号の安全性の議論で必要になる概念である、アルゴリズムの概念や計算複雑性理論について解説をします。

アルゴリズム/計算複雑性理論とは

アルゴリズム（Algorithm）とは、ある問題を解くために人やコンピュータがどういう順番で何をすればよいかを「手順やルールで示したもの」のことです。

計算複雑性理論（computational complexity theory）とは、特定の問題を解くアルゴリズムの実行コスト（解を得るために必要な計算量や記憶領域など）から、その問題の本質的な難しさについて議論し分類する取り組みのことです。
例えば、チューリングマシンにより多項式時間で解ける問題をクラスP、非決定性チューリングマシンにより多項式時間で解ける問題をクラスNPの問題と呼んで分類することがあります。

これらは「具体的なコンピュータプログラム」の実装の優秀性や実用性について議論する手段として、あるいはデータ量や利用者数が増えた時に「ITシステム」がスケールするのかどうかというビジネス的な観点として、あるいは「その問題」がコンピュータで実用的に解くことが出来る問題なのかについて、あるいは「暗号技術の安全性を考える手段」としても利用されます。

「アルゴリズム」とは

アルゴリズムとは、「ある問題」（例えば「数値を小さい順に並べ替える」など）について、「人やコンピュータがそれを解く手順やルール」のことです。例えば、

「コンピュータの中に数値が1万個あり、それを小さい順に並べなおしたい」（問題）に対し、「このような手順でデータを処理すれば並べ替えできます」（手順）がアルゴリズムの例
時刻表と鉄道網の情報があって、「駅Aから駅Bに最短時間で移動する経路はどうやったら解る？」（問題）に対して、「時刻表をこのような手順で調べれば答えが出ます」（手順）がアルゴリズムの例

このように「問題を解く手順」のことを、例えば「並べ替え（ソート）をするアルゴリズム」「最短経路を求めるアルゴリズム」「1000以下の素数を全て求めるアルゴリズム」のように呼びます。

アルゴリズムの例：並べ替え（ソート：Sort）のアルゴリズム

次に、「並べ替え（ソート）をするアルゴリズム」を例に、具体的にどのようなものかを紹介します。

「並べ替える」は日常的に関わることが良くある問題です。「小学生のクラスを身長の低い順番に並ばせる」のもそういう問題ですし、「ホテルを宿代が安い順に並べる」とか「Excelのデータを購入金額が大きい順に並べる」みたいな処理も同じ種類の問題です。

これら問題は「値の大小で並べ替える問題」として同じ本質のものですが、そのような問題は一般的にどう解けばよいでしょうか。

ソートアルゴリズムの例（王様探し）

「数字が100個あります、これを小さい順に整列するプログラムを作ってください」と言われたとします。何も知らない状態から「自分で解く手順を考えてください」と言われると意外と難しくてうまく思いつけなかったり、間違ったものを作ってしまったり（並べ替えができない場合がある、処理が停止しないことがある、入力データと違うデータになってしまっているなど）して、意外と難しかったりします。

難しいことを考えず、素朴にプログラムを実装してうまく行った場合、例えば小学生にプログラミングで作らせた場合には、「王様探し」と呼ばれることもある「一番大きい/小さいものを順次見つけてゆく」方法で実現されることがあります。

A: 全員の中で一番身長の低い人を見つける
- その人を列の先頭に並べる
B: それを除外した残りの人から、一番身長の低い人を見つける
- その人を「その次」に並べる
C: 全員が並び終わるまでBを繰り返す

あるいは以下のような比喩の方が、「この方法で並べ替えがうまくゆく」ことが理解しやすいかもしれません。

全員から一番強い奴を見つけて、その人をキングとする
「その人を除外した全員」から、一番強い奴（キング）を見つける
- 「その次のキング」が見つかる
「さらにその次のキングを見つける」を繰り返すと、強い順での並べ替えが完了する

つまり「一番大きい/小さいものを見つける（王様探し）」処理を繰り返すことで、並べ替えの様々な問題を「一般的に解く」ことが出来ることが解ります。

「アルゴリズム」とは、このような「何かの問題を解く手順」のことです。この例は、「一番大きい/小さい値を順番に見つけてゆけば、並べ替えが済んだ状態になるよね？」という考え方によるアルゴリズムです。

「一番大きい/小さいものを見つける（王様探し）」処理をどうやって実現するかですが、「トーナメント方式で一番を見つけることができる」が誰でもイメージしやすい例かと思います。プログラミングとしてシンプルな例としては「最初にどれか一つを選び、ループ処理命令で残りの全部と比較して残ったものが当然に一番小さいもの」が簡単に作れる例かなと思います。

「王様探し」のアルゴリズムの良いところと悪いところ

ただしこのアルゴリズム、「性能が良くない」問題があります。例えばこの方法でクラスの全員を身長の低い順に並べたとします、「次の一人」を見つけるたびに「最初からの身長の比較」を何度も繰り返すため、同じ人同士の比較が何度も行われる問題があり、多くの人から「私は一体何回無駄に身長を比較するんですか」ということを言われてしまうはずです。

それはつまり「同じデータ量の並べ替えをする」ために必要な「演算処理の量が無駄に多い」ということであり、「アルゴリズムとして性能が低い」ということになります。

アルゴリズムには処理性能が優れたものと、そうでないものがある

ただし「王様探し」のアルゴリズム、処理性能は低いのですが上記の説明の通り「考え方がシンプルで大変理解しやすい」ところは長所です。理解しやすいアルゴリズムは、プログラムとして書きやすくなり、単純明快なので「バグがない」ことも確認しやすくなります。

アルゴリズムは「処理性能」以外にも、「理解しやすいかどうか」など他の観点でも優劣が比較できる

より効率的なアルゴリズムの例、「マージソート（Merge sort）」

では次に「性能に優れたソートアルゴリズム」の例です。ソートアルゴリズムの中でも手順が洗練されていて美しい「マージソート」を紹介します。整列させるまでに比較する回数が大きく減っていることも感じてください。

なお、このアルゴリズムを最初に思いついたとされる人はなんと、現在われわれが使っているコンピュータの方式そのもの（ノイマン式）を考えた天才科学者のフォンノイマンで、このアルゴリズムは1945年に考えついたとされます。伝説的にすごい人は何をやっても「すごい」ようです。

考え方としては、データを全て「二個ずつのグループ」としてグループ内で並べ替えをして、その後「並べ替え済みのグループを二つずつ合体させる」を繰り返して全体を整列済みにします。

以下の8つの数字を並べ替えるとします
- 54283176
二個ずつのグループに分けて並べ替える
- 二個ずつに分けます
  - 54 | 28 | 31 | 76
- グループ内で並べ替えを行います
  - 45 | 28 | 13 | 67
グループを二つずつ、併合(Marge:マージ)する
- グループを、二グループずつの組にする
  - (45 | 28) | (13 | 67)
- グループ二つずつを一つに合体します:
  ポイントは「グループ内では整列済み」であることです。「先頭要素同士を比較する」だけで全体で一番小さいものを見つけることができます。
  - 2458 | 1367
    - | 45 | 28
    - 2 | 45 | 8
    - 24 | 5 | 8
    - 245 | | 8
    - 2458
- 全体が一つのグループになるまで、併合(マージ)を繰り返します
  - 2458 | 1367
  - 12345678

ざっくりしたイメージとしてでもつかんで欲しいのは、「王様探し」では同じ数字同士の大小比較を何度も行っていたのに対して、こちらのアルゴリズムではそのような無駄が無くなっているところです。

他にも多くのソートアルゴリズムがある

素朴に思いつくアルゴリズムの例として「王様探し」（あるいは選択ソート）を、シンプルかつエレガントで高効率なアルゴリズムの例として「マージソート」を紹介しましたが、ソートのアルゴリズムは他にも多くあります。

実際のプログラミングで利用されているライブラリでは「クイックソート」というアルゴリズムが採用されていることが良くありますし、他にも「ヒープソート」や、大小比較せずに並べ替えをする前提において高速にソートができる「基底ソート」など多くのアルゴリズムがあります。

アルゴリズムの違いでどれくらいの性能差が出るか

次に、「王様探し」（選択ソート）と「マージソート」の処理性能がどれくらい違うのかを調べてみましょう。話が難しいなと思ったら数式の話をしているところは斜め読みしてください。

データがN個の場合：「王様探し」（選択ソート）

アルゴリズムの考え方は「王様探し」を繰り返すことでした。

N個のデータから「王様」を見つけるためには、「N-1回の比較演算」が必要になります。王様本人とそれ以外の全員の間で比較が一回行われるためです。
一番小さい値を見つけて、その残りから「王様を見つける処理」を繰り返すわけですから、最初はＮ個で王様探し、次はN-1個で王様探し…、という処理をしています。
するとソート実行に比較演算の総回数は、「（N-1）+（N-2）+ ,,, + 1」となります。

数列の和の公式を使うことで「N×(N-1)×(1/2)」となるので、「入力データの個数がN個」の場合の比較演算の総回数は「1/2×N² - 1/2×N」ということになります。

データがN個の場合：「マージソート」

マージソートで同じように考えてみましょう。

最初の並べ替えは、データがN個あったら1/2×N回の比較演算が必要になる　
- 例ではデータ8個なので「4回」
　
その後の「マージ」処理では、データの状況によって比較演算の回数は異なりますが、最も多い場合でも全データ個数よりは少ないため、多くともN-1回　
- 例ではデータ8個なので、「多くとも7回」
　
「マージ処理をするフェーズそのものの回数」は、一回マージするごとにデータ量が倍になることを踏まえて、「(log₂N) - 1」回　　
- データ8個ならば、「8は2の3乗」であることから3-1で「2回」、そして上記の例でも実際に、「2つを4つにする」「4つを8つにする」で2回マージしている。

そして最初の「1/2×N回」も「多くともN-1回」に含まれるということで話を簡単にすると、「データがN個の場合」の総比較演算回数は大まかに、「Nlog₂N」回ということになります。

具体的にどれくらいの性能差があるのか

数式を見ただけで「これはかなり差があるな」と気が付く人もいるでしょうが、一般的には解りづらいと思うので、具体的なデータの個数でどれくらい差が出るかを計算して確認してみましょう。

	N=10	N=100	N=1000	N=100万
王様探し（選択ソート）	45回 45マイクロ秒	4950回 4.9ミリ秒	499500回 499ミリ秒	499999500000回 138時間
マージソート	33回 33マイクロ秒	664回 0.6ミリ秒	9966回 9.6ミリ秒	19931569回 19.9秒

回数とは上記での通りの比較演算の回数、そして比較演算が一秒間に100万回処理できるとしての処理にかかる時間です（毎秒一メガ回）、今のパソコンの処理能力としてはかなり控えめな想定です。データの個数が増えると、話にならないくらいに処理時間に差が出ることが解ります。

「データが100万個」というのは一見とても多いデータ量に思えるかもしれませんが、例えば「32ビットの整数値データ」（4バイト）で100万個なら、わずか4メガバイト分のデータです。20世紀のパソコンなら処理に苦労するデータ量ですが、今のパソコン（やスマホ）にとってはもはや普通に取り扱えるレベルのデータ量です。

つまり優れたアルゴリズムでプログラムを作っていれば20秒で完了するが、素朴に実装しているだけだと「なんと138時間もかかる」ほどに、「アルゴリズムの優劣により処理時間に大きな差が出る」ことが解りました。データ量が多い場合、適切なアルゴリズムで実装しておく重要さが良くわかります。

なぜこんなに差が出るのか

どうしてこんなにも処理時間に差が出るのでしょうか。それは、それぞれのアルゴリズムの計算時間の式の「この部分」がポイントです。

王様探し（選択ソート）：1/2×N² - 1/2×N 回
マージソート：Nlog₂N 回

強調した部分は、Ｎが増加したときにそれに呼応して「増加する力が最も大きい部分」です。「Ｎ²が増加する」力に比べれば、「Ｎの増加する力」や「Ｎlog₂Nが増加する力」ははるかに弱いので、「アルゴリズムの性能を大まかに考える場合」においては無視できるていどで誤差と考えてよいということです。

「log₂N」がイメージしづらいかもしれませんが、「Ｎ＞ log₂N ＞ 1」の関係がなりたちます。つまり「Ｎlog₂N」もこれに追加すると「Ｎ² > Ｎlog₂N > Ｎ＞ log₂N ＞ 1」となるので「Ｎよりは明らかに大きいが、Ｎの二乗よりは明らかに小さい」ものです。

つまり、データの個数が多くなった時に、比較して王様探し（選択ソート）の実用性が怪しく感じたのは、「Ｎの増加」に伴う「Ｎ²の増加」と「Ｎlog₂Nの増加」に大きな差があるからです。

アルゴリズムの「計算量オーダー」

このような、計算量の式から「一番強い成分」を取り出したものを「アルゴリズムのオーダー（計算量オーダー）」と呼び、「O(N²)」というような表記で記します。

計算量が「1/2×N² - 1/2×N」の王様探し（選択ソート）　
- アルゴリズムの計算量オーダーは「O(N²)」
計算量が「Ｎlog₂N」のマージソート　
- アルゴリズムの計算量オーダーは「O(ＮlogN)」

「端折り過ぎではないか？」と思えるかもしれませんが、このようにすることで、世の中に沢山あるアルゴリズムの性能を、「本質的な性能差で分類してグループ化する」ことが出来ます。それにより、アルゴリズムを性能により一種の「格付け」した状態にでき、どのアルゴリズムが「どのような性能のものなのか」を横断して把握しやすくなります。

例えばここまで読んできただけでも、二つのアルゴリズムの例により処理するデータ量が本格的に多くなった場合に「O(ＮlogN)」と「O(N²)」のアルゴリズムが「どういう感じで差が出るか」はイメージできるようになったかと思います。

その問題の「本質的難しさ」

「並べ替えの問題（ソート）」を解くアルゴリズムの例として「選択ソート（王様探し）」と「マージソート」を紹介しました。当然のことながらソートを実現するアイディアは紹介した二種類だけに限られることはなく、アルゴリズムもこの二種類以外にも無数にあります。

では、「マージソート以上に性能の高いアルゴリズム」は存在するのでしょうか。これに対しても、オーダー表記は解りやすい目安を与えてくれます。大小比較をして並べ替えを行うタイプの「並べ替えの問題（ソート）」では「O(NlogN)が下限」であって、それ以上に優れたものは存在しないことが理論的に証明されています。

つまり残念ながら、それ以上に画期的に高速な新アルゴリズムは探しても見つからないということです。残念な事実ですが、一方で「ありもしない理想のアルゴリズムを探す苦しみ」から解放されて諦めがつくことになりました。O(NlogN)のアルゴリズムの中から、自分たちの事情に合わせた特性があるものを選べば、それで概ねはベストを尽くしたことになりました。

また逆に考えると、「並べ替えの問題（ソート）」は、問題自体の本質的難しさが「O(NlogN)」であるとも言えます。

複雑性クラスP/NP

このような「その問題を解く本質的な難しさ」を議論する分野があり、それが「計算複雑性理論」です。それぞれの問題やアルゴリズムをその難しさにより「複雑性クラス」に分類する際に良く使われるのが「P」あるいは「NP」（NP完全/NP困難）という言葉です。

「P」とは、「多項式時間（Polynomial time）で解くことが出来る」問題のクラスのことで、実質的に「現実的に解くことができる」あるいは「効率的に解くことができる」問題のことです。これに対して「NP」（正しくはNP困難）とは「多項式時間で解くことができない」問題のクラスのことで、実質的に「実用的に解くことができない」問題のことです。

※正しくはPとは「決定性チューリング機械によって多項式時間で解くことができる問題」、NPとは「非決定性（Non-deterministic）チューリング機械によって多項式時間（Polynomial time）で解くことができる問題」のことで、さらに「NP困難」「NP完全」などもそれぞれ意味が異なるのですが説明が難しくなりすぎるので、簡易な説明をしています

「多項式時間で解くことができる」とはどういうことかというと、データの個数がＮなら、「Ｎ²+log₂Ｎ」とか「Ｎ⁶+3N²-N」のような「Nのn乗の範疇の時間で解ける問題」のことです。これに対して「NP」とは「そうではない」もののことで「2^N」のような指数的に計算量が増えてしまうものが該当します。

「Ｎ¹⁰⁰⁰」みたいなものも多項式時間なので、「P」であれば必ず実用的に解けるかというと微妙なのですが、「2^N」では計算量が指数的に爆発するため「少量のデータ以外では解くことが絶望的」であることから区別されています。試しに「2^N」を先ほどの「選択ソートとマージソートの比較」に入れてみると、絶望的な感じが良くわかります。

	N=10	N=100	N=1000	N=100万
王様探し（選択ソート）	45回 45マイクロ秒	4950回 4.9ミリ秒	499500回 499ミリ秒	499999500000回 138時間
マージソート	33回 33マイクロ秒	664回 0.6ミリ秒	9966回 9.6ミリ秒	19931569回 19.9秒
「2^N」のアルゴリズム	1024回 1ミリ秒	1267650600228230000000000000000回 401兆9693億6841万3315年	お察しください	お察しください

ちなみに「宇宙誕生から138億年」に対しての400兆年となります。データがわずか100個になっただけで宇宙誕生直後からずっと計算していても全く間に合わないような異常な計算量ということになります。

このように「NP」（NP困難）とは、「理論上は計算して解く方法が存在するが、実用的には解けないとみなすべき問題あるいはアルゴリズム」のことを分類した複雑性クラスです。

「ビジネスがスケールするか」にも関係するアルゴリズム

またここまで議論してきたような観点は、アルゴリズムを実装して実システムで利用する立場においても、そして何より「ITシステムを用いてビジネスを提供する場合」においても重要です。なぜなら、「Nが増加しても大丈夫かどうか」とは「ITシステムやビジネスがスケールするかどうか」でもあるからです。

例えば、自社でクラウドサービスを提供しているとします。「処理するデータ量が100倍になった時」とか「利用するユーザ数が100倍になった」時に、「処理に必要な計算量はどうなるか」はまさしくビジネス上においても重大な関心事のはずです。

O(1)
- 「データ量が増えても計算量は一定」という理想的な性質のアルゴリズムとなります。
- 例えば「ハッシュテーブルを用いたデータの検索や追加」の計算量は「O(1)」で済みます。
O(logN)
- こちらも「良くスケールする」状況です
- 例えば、「データ量が100倍に増えたのに計算量は10倍に増えるだけ（log₁₀Nの場合）」あるいは「データ量が256倍に増えたのに計算量は16倍に増えるだけ（log₂Nの場合）」のような状況です。
- データ量が非常に増大しても計算量（実現コスト）はさほど増えずに済むため、ビジネスにおいても良好な性質です。
- 「ソート済みデータを探索（検索）処理する」計算量などが該当します。
O(N)
- 「データ量に比例して計算量が増える」場合です。
- 「データが10倍だから処理負荷も10倍」と直感的であり、利用者にもコスト構造が理解しやすい状況です。
- 「ソートされていないデータを探索（検索）処理する」「大小比較によらない並べ替え処理（基底ソートなど）」などの計算量が該当します。
O(NlogN)
- データ量の増加よりも計算量の増加が大きいものの、比較的にスケールする場合です。
- すでに紹介したように「並べ替え（ソート）のアルゴリズム」の計算量などが該当します。
O(N²)
- ある程度までのデータ量なら実用的に解くことができますが、データ量が多くなってくると処理が厳しくなります。
- Nが増えると実用的に処理できなくなってくることから、ビジネス上も「そういう状況にならない」ように注意しておく必要があります。
- 「選択ソート（王様探し）などの工夫されていない並べ替え（ソート）のアルゴリズム」などが該当します。
- さらに、O(N³)やO(N⁶)になってくるとより状況は厳しくなってきます。
O(2^N)など
- 世間的に「NP」（正しくはNP困難）と呼ばれているような問題やアルゴリズムのことです。
- 問題を十分に工夫して解くことができず、本質的に「解の候補をしらみつぶしに探して解くことしかできない」ような場合にそうなります。
- 「Nがごく少ない数」である場合しか、実質的に解くことが出来ません。「NPになってしまう」ことは、ビジネス上も非常に注意せねばなりません。
- 「NP」となってしまう問題の例
  - 巡回セールスマン問題：N個の都市を全て訪問する最短ルートを見つける問題
  - ナップサック問題：合計重さXkgまでの制限で合計金額が最大になる商品の組み合わせを見つける問題
- 何らかの最適化問題を解きたい場合など、実務的に解く価値が高い問題がこの複雑性クラスに所属していて、残念ながら解けないことどうにもあります。
- ただし、「最適解」を求めようとすると「NP」になってしまうが、「近似解」で良ければ「P」で解を求められるアルゴリズムが存在していて実用的に解くことが出来る場合もあります。
「解けない」問題
- さらには「決められた手順で必ず解を得る方法がない」という絶望的なこともあります。
- 解こうとしても答えが得られることが一切ないわけではなく、「特定の場合に解ける」ことや「偶然に個別解がみつかる場合」はあっても「任意の入力に対して決められた手順で必ず解を得る方法」そのものがない場合です。
- 例えば「任意のプログラムを入力として、そのプログラムが停止する性質があるか、永久に停止しないか、そのどちらかであるか」を判定する問題（停止問題）は「一般的に解く方法が存在しない」ことが解っています。

計算量が多くなりすぎる場合には、サービスの提供原価がかさむことになりますし、処理完了まであまりにも時間がかかるようでは顧客から「使い物にならない」と苦情が出てしまいます。

よりスケールする性能の高いアルゴリズムでの実装に努めるか（「そのようなアルゴリズムが存在すれば」ですが）、あるいは「データ量が多くなりすぎない使い方」だけで利用されるように、サービスの売り方など「ビジネス展開そのものを工夫しておく」必要が出てきます。

他社との競争におけるアルゴリズム

競合他社が「O(N²)」のアルゴリズムで実装をしていて、自社が「O(logN)」で済む優れたアルゴリズムで実装をしていたとします。処理するデータ量（や利用ユーザ数）が100倍になった時に競合の提供原価は1万倍になり、自社は10倍で済むので大きな差が付くことになります。

このコスト構造のまま「データ量での製品比較をする売り込み」の大攻勢をかけて戦いに引きずりこむことが出来れば、競合他社のみをサービス維持が困難な状況に追い込むこともできます。

アルゴリズムというと、エンジニアだけに関係するような技術的な話題に思えるかもしれませんが、このようにビジネスのレベルでも、意識すると良いことがあります。

「安全性」としての「実質的に計算できません」

ここまでは「計算する」「計算できる」ことが価値を生み出す場合での話をしてきました。次にその逆の「計算できない」ことが価値を生み出す話をします。

昨今では「セキュリティ」は大変に重要な話題です。ITにおいて「安全安心」を確保する手段として重要な要素であるのが「暗号技術」です。パスワードなどの秘密情報を知らない第三者には「暗号文を元のデータ（平文）に戻すことができない」ことでデータの安全安心を守ることが、つまり暗号技術の有用性です

ところで、「暗号技術が安全である」とはどういう状態のことだと思いますか。「暗号を解読する手順が存在しない」ことを指すように思えるかもしれませんが、実はそうではありません。

世間的なイメージでの安全な暗号技術
- 「暗号文」だけが手元にある状態で「平文」（暗号化する前のデータ）を復元することが不可能である

物理的なセキュリティの話に例えると、万全の警備により侵入不能なので安全、と言う感じでしょうか。

現代においてデータを暗号化する場合、「AES暗号」などの「公開技術の暗号」を用いることが普通です。公開技術ですから「どういう処理手順で暗号化しているか」がそもそも秘密ではなく公開されているため、「暗号文を平文に戻す方法」も最初から秘密ではありません。

現実の暗号技術
- 「暗号文」だけが手元にある状態で「平文」を復元する方法は、最初から分かっていて世間にも公開されている

「暗号が安全である」とは、「解読する方法は（一応）解っている」けれども「計算量が爆発してしまうために、現実的には無理」なことなのです。

実際の「安全な暗号技術」
- 入力された平文を「実用的な計算量」で暗号文に変換できる
- パスワードなどの秘密情報を知っていれば、暗号文を「実用的な計算量」で平文に戻せる
- 暗号文をパスワード無しで平文に戻すアルゴリズムは存在するが、「実用的な計算量で平文に戻すことができない」ことで、暗号技術が安全であると考える

先ほどの物理的なセキュリティの話に例えてみるなら、「誰でも入り込むことはできる」けれども「内部に到達するまでが大変すぎて全員力尽きてしまう」ので実質侵入できないのと同じ、という感じでしょうか。

つまり、現代において「暗号技術が安全である」とは「解読する方法がない」のではなく、「既知の解読方法では、計算量が多くなりすぎて現実的に解読できない」ので安全であるという計算量やアルゴリズムの話なのです。

アルゴリズムとのかかわり方を考える

すでに紹介したように、アルゴリズムや計算量の話とは、エンジニアがプログラミングをするような状況で必要な専門知識であるのみならず、自社がITを用いて何かをするときに、ビジネスのレベルからも意識した方が良いことがあります。

人材採用で考慮すべき点であること

ソートのアルゴリズムの例でみてきたように、適切なアルゴリズムで実装されている場合とそうでない場合には、出来上がったITシステムの性能が大きく違うことがあります。不適切な実装がなされている場合、データ量が少し増えただけで計算量やメモリ消費量が異常に増えてしまって支障が出てしまうことがあります。

エンジニアの採用、あるいはITを用いたビジネス設計を担当する人材を採用する場合に、アルゴリズムなどの計算機科学の基礎が身についているかどうかを確認する方が良いはずです。あるいは、ともすると軽視されていることもある情報処理技術者試験のような座学での知識の研鑽けんさんをやっていないままシステム開発を行うと、どのようなことが起こってしまうのか、が今回紹介させていただいたことかもしれません。

自社のビジネスを支えているITシステムを、アルゴリズムの観点で確認する

自社ビジネスを支えているITシステム、あるいはクラウドサービスを自社で提供しているのなら自社サービスについて、それぞれの機能がデータ量やユーザ数が増えた時にどうなるかを一度調べてみると良いかもしれません。

データ量が増えると性能が出ないような場合には、より優れたアルゴリズムで実装しなおすことを検討すべきでしょう。そもそも優れたアルゴリズムが存在しない場合には、データ量を増やさない前提でビジネス自体を組み立てる必要が出てきます。逆に、良好にスケールすることが解った場合には、データ量や利用者が増加してもコスト的には負担が大きくなりにくいわけですから、そのポイントでの攻めのビジネスが良い結果を生むことが期待できます。

優れたアルゴリズムが、自社の競争力を生む資産になりうる

例えばITシステムにより荷物の配送経路の最適化を実現したい場合、多くの場合には最適解を求めるアルゴリズムはクラスNPの問題であるため、実用的な規模の問題を解くことは難しくなります。ただしそのような場合にも、実用的な計算時間で「近似解」を求めるアルゴリズムが存在することがあります。

例えば、他社ではあまりよく考えていないアルゴリズムで配送計画を作成しているため商品の配送コストが年間100億円かかっているが、自社では優れた近似アルゴリズムを用いることで80億円のコストで済んでいるのなら、アルゴリズムの差が競争力の差になりえます。

データを自社の資産と考えることや、優れた機械学習の学習済みモデル、あるいは自社独自のLLMを資産と考えるのと同じように、「自社の事情に即した優れたアルゴリズム」についても、自社の競争力を生み資産になりえるのではないでしょうか。

現実には「すでにあるもの」を組み合わせて使うことになる

優れたアルゴリズムで実装されたITシステムを利用することが望ましいわけですが、しかしながら昨今では自社で利用する全てのITシステムを全て独自にスクラッチ開発することはあまり現実的ではなくなりました。

自社にとって重要な部分については独自開発するとしても、既存のパッケージソフトウェアや既存のクラウドサービスを利用する、つまり「世の中にすでに存在するもの」を「うまく組み合わせて利用する」ことが現実的になってきました。

そうなってくると、自社で開発するのではなく、世の中に「既にあるもの」のなかから「優れたアルゴリズムで実装されていると思しき既存ソフトウェアやクラウドサービス」を探してきて用途に応じて適宜組み合わせて利用することになります。そうなると、こんなことが起こってきます。

クラウドサービスAはとても使いやすいと現場に大評判だが、データ量が増えると処理が非常に遅くなる問題があることが解ってきた
クラウドサービスBはデータ量が増えた時の処理性能はとても優れているが、利用コストが高く全面的な利用が難しい
クラウドサービスCは基本的機能での処理性能は比較的によく、コスト面でも優れているが、機能面で劣っていてできないことがあり、主要機能以外では処理性能が悪い場合もあり全面的な利用が難しい

このような状況では、どれか一つのクラウドサービスだけを利用することは難しく、複数のクラウドサービスをうまく組み合わせて利用することが望まれることになります。

「既存のものをうまく組み合わせて活用する手段」として活躍する「つなぐ」技術

「自社にとって重要な部分」は独自システムとして最適な仕様と最適なアルゴリズムで実装するのだとしても、それ以外の部分は既存のクラウドサービスなどを利用して「すでにあるもの」を必要に応じて上手に活用することが多いはずです。

さらには、良いクラウドサービスだと思って利用しはじめたものに、後になってから問題点が見つかってくることもあり、事後に他のクラウドサービスを組み合わせて利用せざるを得なくなることもあります。ビジネスの状況が変わり、データ処理において重要視すべきことが変化する（例えば、少人数の顧客相手だったビジネスが、何十万人もの顧客データを遅滞なく処理する必要性があるビジネスに変わるなど）こともあります。

そうなると、「複数のクラウドサービスなどをうまく組み合わせて利用できる」のみならず、ビジネスの現場で試行錯誤しながら「状況に応じてその都度、利用するクラウドサービスの組み合わせを切り替えられる」ようにしておく必要が出てきます。

「つなぐ」技術を活用ください

このような各種の「連携処理」を、「GUIだけ」で効率的に開発できる手段が存在します。「EAI」や「ETL」、「iPaaS」と呼ばれる、「DataSpider」や「HULFT Square」などの「つなぐ」技術です。これらを活用することで、新旧システムをスムーズかつ効率的に連携させることができます。

GUIだけで利用できる

通常のプログラミングのようにコードを書く必要がありません。GUI上でアイコンを配置し設定をすることで、多種多様なシステムやデータ、クラウドサービスへの連携処理を実現できます。

「GUIで開発できる」ことは長所でもある

GUIだけでのノーコード開発は、本格的なプログラミングに対して簡易で妥協的な印象を受けるかもしれません。しかしながら、GUIだけで開発できることは「業務の現場の担当者が自分たち自身で主体的に連携処理の実現に取り組む」ことを可能にします。ビジネスのことを一番良くわかっているのは現場の担当者です。

本格的処理を実装できる

「GUIだけで開発できる」ことを謳っている製品は沢山ありますが、そういう製品に簡易で悪い印象を持っている人もおられるかもしれません。

確かに、「簡単に作れるが簡易なことしかできない」「本格的なデータ量で処理を実行しようとしたら処理できずに落ちてしまった」「業務を支えられるだけの高い信頼性や安定稼働能力がなくて大変なことになってしまった」ようなことは起こりがちです。

「DataSpider」や「HULFT Square」は、簡単に使うこともできますが本格的プログラミングと同等のレベルの処理の作りこみもできます。内部的にJavaに変換されて実行されるなど本格的プログラミングと同様の高い処理能力があり、長年にわたって企業ITを支えてきた実績もあります。業務での利用が進んでデータ量が増えた時にも実用的に利用できるのか？にもすでに配慮がなされていいます。「GUIだけ」の良さと、本格的能力の両方を兼ね備えています。

iPaaSなので自社運用不要

DataSpiderなら自社管理下のシステムでしっかりと運用できます。クラウドサービス（iPaaS）のHULFT Squareなら、このような「つなぐ」技術そのもの自体もクラウドサービスとして自社運用不要で利用でき、自社での導入やシステム運用の手間がなく利用できます。

関係するキーワード（さらに理解するために）

EAI
- システム間をデータ連携して「つなぐ」考え方で、様々なデータやシステムを自在につなぐ手段です。IT利活用をうまく進める考え方として、クラウド時代になるずっと前から、活躍してきた考え方です。
ETL
- 昨今盛んに取り組まれているデータ活用の取り組みでは、データの分析作業そのものではなく、オンプレミスからクラウドまで、あちこちに散在するデータを集めてくる作業や前処理が実作業の大半を占めます。そのような処理を効率的に実現する手段です。
iPaaS
- 様々なクラウドを外部のシステムやデータと、GUI上での操作だけで「つなぐ」クラウドサービスのことをiPaaSと呼びます。

「iPaaS」や「つなぐ」技術に興味がありますか？

オンプレミスにあるITシステムからクラウドサービスまで、様々なデータやシステムを自在に連携し、IT利活用をうまく成功させる製品を実際に試してみてください。

「つなぐ」ツールの決定版、データ連携ソフトウェア「DataSpider」および、データ連携プラットフォーム「HULFT Square」

当社で開発販売しているデータ連携ツール「DataSpider」は長年の実績がある「つなぐ」ツールです。データ連携プラットフォーム「HULFT Square」はDataSpiderの技術を用いて開発された「つなぐ」クラウドサービスです。

通常のプログラミングのようにコードを書くこと無くGUIだけ（ノーコード）で開発できるので、自社のビジネスをよく理解している業務の現場が自ら活用に取り組めることも特徴です。

DataSpider / HULFT Squareの「つなぐ」技術を試してみてください：

簡易な連携ツールならば世の中に多くありますが、GUIだけで利用でき、プログラマではなくても十分に使える使いやすさをもちつつ、「高い開発生産性」「業務の基盤（プロフェッショナルユース）を担えるだけの本格的な性能」を備えています。

IT利活用の成功を妨げている「バラバラになったシステムやデータをつなぐ」問題をスムーズに解決することができます。無料体験版や、無償で実際使ってみることができるハンズオンも定期開催しておりますので、ぜひ一度お試しいただけますと幸いです。

無料製品紹介セミナーはこちら

「HULFT Square」で貴社のビジネスが変えられるか「PoC」をしてみませんか：

貴社のビジネスで「つなぐ」がどう活用できるのか、データ連携を用いた課題解決の実現可能性や得られる効果検証を行ってみませんか？

SaaSとのデータ連携を自動化したいが、その実現可能性を確認したい
データ利活用に向けて進めたいがシステム連携に課題がある
DXの実現に向けてデータ連携基盤の検討をしたい

PoCプログラム | HULFT Square