MENU

生成AIはIPOで変わる

生成AIを使っていて、こう感じたことはないだろうか。

「思っていたのと違う出力が返ってくる」

「毎回、質が安定しない」

「結局、自分でやり直した方が早い」。

多くの人はこれを、AIの性能の問題だと思っている。だが、実際はそうではないことが多い。

原因は、生成AIを扱うときの最小単位——Input・Process・Output——を意識せずに使っていることにある。

目次

生成AIが変えたのは、情報処理そのものの姿

そもそもIPOとは何か。

Input・Process・Outputは情報処理の最小単位

そもそも情報処理という言葉の定義に立ち返ると、こうなる。

「目の前の情報を、目的に沿った情報に変換すること」だ。

これ自体は、コンピュータが登場するよりずっと前からある話だ。人間が紙とそろばんで帳簿をつけるのも、工場で原材料を製品に加工するのも、突き詰めれば情報処理(あるいはそれに準ずる処理)だ。目の前にあるもの(Input)を、決まった手順(Process)で、目的の形(Output)に変換している。

コンピュータは、この情報処理を機械的に高速化しただけの存在だった。だから従来の情報処理は、Input・Process・Outputのそれぞれが固定化されていた。決まったフォーマットのデータを、決まった手順で、決まったフォーマットの結果に変換する。これがコンピュータの情報処理の基本だった。

例えば会計ソフトを考えてみる。Inputは、決まった項目に沿って入力された数値データだけだ。Processは、あらかじめ組まれた計算式や集計ロジックで、これは変えられない。Outputも、決められた帳票フォーマットでしか出てこない。Input・Process・Outputの3つとも、あらかじめ人間が固定してしまっている。だからこそ安定して同じ結果が出る代わりに、決められた形以外のことは何もできない。

生成AIは、この「固定化」をまるっと崩した。

Inputの変化。 従来は構造化されたテキストデータでなければ処理できなかった。だが生成AIは、非構造化データ、画像、動画まで読み込ませることができる。手書きのメモを写真で撮って読み込ませる、現場の様子を動画で見せる、雑然とした議事メモをそのまま渡す——極端に言えば、「読み込ませればInputは完成する」という状態になった。

Outputの変化。 従来は決まった形式でしか出せなかった出力が、目的に合わせていかようにも変えられるようになった。同じ商談の記録からでも、「箇条書きで」「表で」「上司向けの丁寧な文体で」「3行で」と欲しい成果物の形を変えるだけで、いくらでも違うOutputを取り出せる。

Processの変化。 そして最も大きいのがここだ。Processとは、突き詰めれば、「Inputに対して、目的とするOutputを無理やり接続する操作」でしかない。

従来のProcessは、「もしこうだったら、こう処理する」「もしこうだったら、こう処理する」という条件分岐を、延々と純接でつないだものだった。会計ソフトの計算式も、業務システムのロジックも、この分岐の連鎖でできている。つまり従来は、InputからOutputまでの経路を、人間が一本ずつ手順として書き下す必要があった。

だが生成AIは、この条件分岐の連鎖を、一つのProcessとしてまるごと引き受けてくれる。InputとOutputさえある程度固定してしまえば、その間をどうつなぐかを、AI自身が言語化しながら「いい感じに」処理してくれる。分岐を一つひとつ設計しなくても、目的さえ渡せば、処理そのものを組み立ててくれる——これは地味に見えて、実はかなり大きな変化だ。

つまりIPOという型そのものは変わっていない。だが、InputとOutputの自由度が跳ね上がり、その間をつなぐProcessの多くをAI側が肩代わりできるようになった——これが、生成AIが情報処理に起こした変化の正体だ。

従来の情報処理と生成AIの情報処理の比較

その情報処理の連続体の先に、自動化がある

ここまでの話は、あくまで一つのInputを一つのOutputに変換する、という情報処理レイヤーの話だ。多くの人が生成AIに期待しているのは、実はこの一つ先にある。

情報処理レイヤー:Input・Process・Outputという最小単位で、一つの変換を設計する層
ワークフローレイヤー:その情報処理を複数つなぎ、連続させて回す層——これが「自動化」の正体

情報処理レイヤーとワークフローレイヤー(自動化)

自動化とは、情報処理と対立する別物ではない。情報処理を連続体としてつないだ、その先にあるレイヤーに過ぎない。一つひとつのIPOが安定して初めて、それを連結して自動化というワークフローが組める。

最近よく話題になる「AIエージェント」による自動化も、正体はこれだ。メール受信を見て、内容を判断して、返信を作って、必要ならカレンダーに予定を入れる——これは、複数のIPOを連続でつないだ、ワークフローレイヤーの話にすぎない。

情報処理の連続体の先に自動化がある

だからこそ、土台となる情報処理レイヤーが安定していないと、話にならない。一つ一つのIPO(例えば「この問い合わせメールを分類する」という処理一つ)の精度がブレブレのまま、それを5つ、10個とつなげたらどうなるか。最初の1つでズレたInputやOutputが、次のIPOのInputになり、ズレはどんどん増幅していく。どれだけ壮大なワークフローを設計しても、土台が不安定なら、結局は机上の空論で終わる。

多くの人はこの順番を飛ばす。「これをやって」と投げて、いきなりワークフローレイヤーの結果——決まった手順で、決まった通りに、毎回同じものが返ってくること——を期待してしまう。土台となる情報処理レイヤーのIPOが固まっていないのに、その先のワークフローレイヤーの安定を求めているということになる。安定するわけがない。

だから、慌てて自動化(ワークフローレイヤー)から手をつける必要はない。まずは目の前の一つのIPO——例えば「この問い合わせをどう分類するか」「この文字起こしから何を拾うか」——について、判断基準やルールを言語化し、限りなく安定したOutputが出せる状態を作ること。この情報処理レイヤーの地固めこそが、後々の自動化を「使える自動化」にする一番の近道になる。

一つのInputから、無数のOutputが生まれる

情報処理レイヤーの変化が実務レベルで何を意味するか。一番わかりやすい例で考えてみる。

商談の文字起こしという、たった一つのInputがあるとする。従来なら、これは「議事録を作るための材料」でしかなかった。

だが生成AIを通せば、同じ一つのInputから、目的次第でまったく違うOutputを取り出せる。

一つのInputから無数のOutputが生まれる

Processの部分——「議事録として整形する」「提案書の構成に流し込む」「メールの文体に変換する」——はそれぞれ違う。だが、それをいちいち人間が手順として書き下さなくても、生成AIは目的(Output)を示すだけで、その接続をやってくれる。

一つの情報から、無数のベクトルに向かって成果物を取り出せる。これは、Inputを一度取得すれば使い道が固定されていた従来の情報処理では、原理的にできなかったことだ。

Processは言語化できていなくていい、という話ではない

ここまでの話を聞くと、「じゃあProcessは考えなくていいのか」と思うかもしれない。だが、実際に多くの人が詰まっているのは、まさにこのProcessの部分だ。

InputとOutputは比較的言語化しやすい。「これを渡した」「これが欲しい」は、誰でも説明できる。だがその間で、AIが実際にどう考えて接続したのか——Processの中身——を言語化できている人は、意外と少ない。

ただ、これは弱点ではない。言語化できていなくても、期待通りのOutputが一度出た瞬間、そのProcessを次回にも接続できる形で残すことができる。

これが、Claudeの「スキル」という機能の正体だ。そして、その資産化されたProcessを複数つなげたとき、初めて冒頭の「ワークフローレイヤー」——自動化——が姿を現す。

Processは言語化できていなくていい、Claudeのスキル

IPOで生成AIを使いこなす人が持っている習慣

出力が安定している人と、そうでない人の違いを整理すると、こうなる。

IPOで生成AIを使いこなす人が持っている習慣

才能でも、プロンプトの上手さでもない。生成AIを情報処理として捉え、Input・Process・Outputという最小単位で扱えているかどうか。この一点に尽きる。

· · ·

いきなりワークフローレイヤーの安定を求めている限り、生成AIを使うたびに期待と結果のズレにストレスを感じ続けることになる。

だが土台にある情報処理レイヤーから捉え直した瞬間、扱うべきものはシンプルになる。何を渡すか(Input)、何を出させるか(Output)。この2つの自由度が上がったことで、Processの多くはAI側が引き受けてくれるようになった。そして、うまくいったProcessを資産として残していけば、その先に、初めて自動化というワークフローレイヤーが見えてくる。

生成AIの出力に振り回されている人ほど、実はAIの性能を疑う前に、目の前の一つのInputから、まだ何種類のOutputを引き出せていないかを見直した方がいい。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

目次