Blog一覧

ー つながり(ユーザ接点)を競うビッグテック ー 今日の情報インフラにとって欠かせないものとして、ソフトウェアとサービスの話をしました。次にお話しするのは利用者とのつながり（ユーザ接点）ということです。サービスもソフトウェアも目的を達するための大事な手段です。サービスやソフトウェアを駆使して情報インフラが互いに競い合うのは、ユーザをどうつなぎとめるかということです。その成否が決まるバトルフィールドがユーザ接点です。 江戸時代の天守閣然り、日本では大事なものほど奥に置かれています。昭和の時代に日本企業が築き上げた情報インフラでも大事なもの、例えばデータベースやバッチプログラム、ストレージなどはデータセンターの奥に設置されており、ユーザ・顧客の目にふれるようなものではありません。昭和の情報インフラを築き上げた日本の情報産業も日本の伝統的なものづくり文化をしっかり引き継いできました。重厚長大な情報システムを作り上げることが目的の大規模システム構築の常識では、大事なものが利用者から最も遠いところに置かれているのがあたりまえでした。利用者は間違えるし、人に

ー インフラを「サービス」へ進化させたExodus ー 1990年代半ばから2000年代初頭にかけての「ドットコム・バブル」期は、インターネットが学術的ネットワークからグローバルな商業インフラへと変貌を遂げた時代でした。この爆発的な成長期において、物理的なインターネット基盤であるデータセンタ（Internet Data Center: IDC）の先駆者として君臨したのが、Exodus Communications（以下、Exodus）です。1994年に創業したExodusは90年代の終盤には世界のトップウェブサイトの40%をホスティングする巨大企業へと急成長を遂げ、ピークの2000年には約320億ドルの時価総額を記録しました。 当時は、自社オフィス内のサーバールームでウェブサーバーを管理・運用することが一般的でした。しかしeコマースの台頭とトラフィックの指数関数的な増加によって、オフィス内部での運用管理はネットワーク帯域幅、安定した電源供給、そして高度なセキュリティの観点から非効率かつハイリスクなものとなっていました。Exodusは「ミッションク

ソフトウェアを情報インフラの主役に押し上げた「APIマンデート」 社会インフラとしての情報システムも、ダムや高速道路と同様、始まりはハードウェアを主役とするものでした。コンピュータの巨人、IBMの時代についてはそのうち触れることにして、ここではソフトウェアが決定的にハードウェアを支配することになったターニングポイントについて語りたいと思います。 Windows95が一世を風靡した1995年を経て、インターネットバブルの時代がやってきます。ソフトウェアの役割は大きなものになっていましたが、それでもコンピュータ業界の主役はIBM、HP、Sun Microsystemsといったハードウェアメーカでした。日本でも富士通、NEC、日立製作所が不動の地位を獲得していました。ところがこの頃、ソフトウェアの生産性に革命を起こした出来事がアメリカで生まれます。「APIエコノミー」と呼ばれる新たなアーキテクチャはコンピュータ言語の進化ではありません。このアーキテクチャは当時、インターネットで書籍を販売していたAmazonで生まれました。 Amazonのインターネット

ー 過去に学ぶ、情報インフラの変革 ー インフラと聞いて、何を思い浮かべるでしょうか。道路や水道、通信網といった物理的な基盤を想像する人が多いかもしれません。一方、IT業界に身を置く私たちにとって、情報システムはインフラそのものだと言えます。かつてのメインフレームコンピュータで「構築」された企業の中核となる情報システムは「基幹系システム」と呼ばれました。ことさら「構築」とか「開発」といった言葉が使われるのも橋や道路と同じような公共インフラの建設を意識してのものではなかったかと思います。東京デジタルアイディアーズと私たちは長いこと情報システムによるインフラとともに過ごしてきました。インフラは企業にとって最も重要な戦略と表裏一体の関係にあります。企業戦略の成否を分けるのはインフラだといって過言ではないと思います。ここではインフラについて東京デジタルアイディアーズからいくつかの観点で語ってみることにいたします。 このブログでは情報システムの進化とともにインフラの役割がどのように変化していったかについて語りたいと思います。情報システムが社会インフラとな

生成AIの競争軸は大規模言語モデル（LLM: Large Language Model）の「回答精度」を競うフェーズから、実務を完結させる「自律型AI（Agentic AI）」の性能を競うフェーズへと劇的に移行しました。アメリカの巨大テック企業はいずれもAgentic AIの大胆な活用をソフトウェア開発に活かしており、生産性の爆発的な改善に関する報告が相次いでいます。またその結果、エンジニアの大量解雇や「SaaSの死」と呼ばれるIT企業の株価暴落へとつながっています。 一方、日本ではどうでしょうか。IT企業の株価低迷の影響こそあったものの、Claude Codeでソフトウェア開発の生産性が爆上がりしたという話はまだあまり耳にしません。逆に開発現場の話を聞いてみると例によってできない理由が次々と発覚しているようなのです。 意識高い系のエンジニアたちと議論してわかった日本企業ITの壁はいつか来た道を想い出させます。かつてのPC革命もインターネット革命も日本企業では同じ壁にぶちあたってしまいました。本レポートでは日本企業において生成AIによるソフトウェ

こんなブログが注目を受けています。 「Claude Codeで「AI部下10人」を作ったら、勝手にバグ直して「違反は切腹」ルールを追加してきて、オレは適当にしゃべるだけになった」 https://zenn.dev/shio_shoppaize/articles/5fee11d03a11a1 詳細はオリジナルを見てもらうとして、このブログで紹介されているのはこんなことです。Claude Codeで作成した10個のAgentにそれぞれ将軍、家老、足軽といった役割を定義して、それぞれがやってもいいこと、いけないことをユーザである「上様」がルールとして定めます。その上で「コレコレを作って」と将軍に命令するとなんと10個のAgentがせっせとソフトウェアを開発しはじめたというのです。それだけではありません。将軍は「上様、この作業パターン、スキル化したら便利では？」とAgentがユーザに提案までしてくるのです。「バグを作ったら切腹」というルールがあるというのも興味を引きます。切腹しても新しいAgentを誕生させれば生産性は変わらないのです。...

GoogleはAgenticコマースの仕組みで小売マーケットへ切り込もうとしています。この仕組みが完成系に近づけば、ECの雄、Amazonのお株が奪われてしまうかも知れません。Agenticコマースが何を目指しているのか、まずは日経新聞の記事をご覧ください。 出所）「米国でAI使った「アマゾン飛ばし」　GAPは買い物エージェント導入」 日本経済新聞 2026年4月9日 https://www.nikkei.com/article/DGXZQOGN30ALM0Q6A330C2000000/ GoogleのAgenticコマースはAgent to Agent Protocol (A2A)とA2Aの応用版として考案されたAgent Payments Protocol　（AP2)によって動いています。この仕組みはAgenticコマースを推進するためにGoogleが提唱し、数十社のIT企業やカード会社などがパートナとしてコンソーシアムに参加しています。 https://cloud.google.com/blog/products/ai-machine-le

日本企業のエンジニアたちもAgentic AIに取り組みはじめています。ある友人はAnthropic社の提唱するMCPサーバを利用して、業務システムとAI Agentとの接続に挑戦しました。この方式は既存システムとAI Agentを組み合わせて利用できるとして、大変注目を受けています。 大企業の業務システムは業務フローのステップごとにいくつも連なって一連の業務の流れを作っています。業務システムと業務システムとの間には事務スタッフの作業が入り込んでいます。チェックしたり、承認をとったり、追加データを入力したりするステップです。それら事務スタッフがこなす作業をAI Agentにやらせることができれば、全体の業務プロセスが大幅に簡略化できます。いわばGoogleが挑戦しているAgenticコマースの社内システム版です。 一つ一つのやりたいことは単純なのですが、実際にやり始めてみると友人は色々な難題にぶつかってしまいました。社内に散らばっている業務システムがバラバラで、うまくつながらないのです。業務システムにはそれぞれアクセス権限が設定されています。詳細