
構造化する技術(第1回)― 乱雑な情報から複数の射影へ
同じ会社の記録が別々に集計されるのはなぜでしょうか。名寄せから始め、身近なデータを検索や集計に使える形へ変える方法を扱います。
Alopex ファミリー
Asopitech Labo
エンタープライズ構想

同じ会社の記録が別々に集計されるのはなぜでしょうか。名寄せから始め、身近なデータを検索や集計に使える形へ変える方法を扱います。

その問題定義、書いて終わりにしていませんか? 仮説として更新し、要件定義へ渡すまでの手順です。


その依頼、すでに選ばれた解決策ではありませんか? 方法は脇に置き、現状との差として問題を書きます。

その開発、予算がついた時点で結論が決まっていませんか? 作らない判断を妨げる七つの構造を解説します。

その要求、担当者の作業一覧から拾っていませんか? 業務の全体像を捉え、システム化の範囲を決める手順です。

そのシステム化の依頼、問題ではなく解決策が書かれていませんか? 開発対象を消していく手順を整理します。

エージェントにカード番号を渡す話ではありません。では、この一年で積み上がった規格は、何を証明しようとしているのでしょうか。

そのコードは、次のモデルが来ても必要ですか? 着手する前に検証すべき6つのポイントを紹介します。

独自の長期記憶、ワークフローDSL、モデルルーター。作れば動くし、技術的にも面白い。それでも、三か月待てば要らなくなるとしたら?

Claude Codeを作ったBoris Chernyは、8か月も手でコードを書いていないと言います。プロンプトを磨く仕事は、ループを設計する仕事に変わるのでしょうか?

コードは動き、テストも通る。それでも使う価値だけが消えていく。AI時代の実装が抱えるこの壊れ方を、技術的負債ではなく「座礁資産」として紹介します。

PDF対話もAIプレゼンもChatGPTプラグインも、いまはChatGPTやGeminiの標準機能です。それを支えた実装は、どこへ行ったのでしょうか?

アメリカでIT企業といえばMicrosoftやNVIDIA、日本ではNTTデータや富士通——同じ「IT企業」でも指すものが違います。製品を世界へ量産する米国型と、顧客固有の業務を支える日本型。この構造差が収益・人材・競争力を分けてきました。生成AIはこの構図をどう再編するのか、日本の弱みと強みから展望します。
同じ会社の記録が別々に集計されるのはなぜでしょうか。名寄せから始め、身近なデータを検索や集計に使える形へ変える方法を扱います。
その問題定義、書いて終わりにしていませんか? 仮説として更新し、要件定義へ渡すまでの手順です。
その問題、どこまでを対象にしますか? 四つの軸で、問題の範囲と見方を決めます。
その依頼、すでに選ばれた解決策ではありませんか? 方法は脇に置き、現状との差として問題を書きます。
その開発、予算がついた時点で結論が決まっていませんか? 作らない判断を妨げる七つの構造を解説します。
その要求、担当者の作業一覧から拾っていませんか? 業務の全体像を捉え、システム化の範囲を決める手順です。
そのシステム化の依頼、問題ではなく解決策が書かれていませんか? 開発対象を消していく手順を整理します。
エージェントにカード番号を渡す話ではありません。では、この一年で積み上がった規格は、何を証明しようとしているのでしょうか。
そのコードは、次のモデルが来ても必要ですか? 着手する前に検証すべき6つのポイントを紹介します。
独自の長期記憶、ワークフローDSL、モデルルーター。作れば動くし、技術的にも面白い。それでも、三か月待てば要らなくなるとしたら?
Claude Codeを作ったBoris Chernyは、8か月も手でコードを書いていないと言います。プロンプトを磨く仕事は、ループを設計する仕事に変わるのでしょうか?
コードは動き、テストも通る。それでも使う価値だけが消えていく。AI時代の実装が抱えるこの壊れ方を、技術的負債ではなく「座礁資産」として紹介します。
PDF対話もAIプレゼンもChatGPTプラグインも、いまはChatGPTやGeminiの標準機能です。それを支えた実装は、どこへ行ったのでしょうか?
アメリカでIT企業といえばMicrosoftやNVIDIA、日本ではNTTデータや富士通——同じ「IT企業」でも指すものが違います。製品を世界へ量産する米国型と、顧客固有の業務を支える日本型。この構造差が収益・人材・競争力を分けてきました。生成AIはこの構図をどう再編するのか、日本の弱みと強みから展望します。