解決策の議論を促進するための転換をしよう

ども、明けましておめでとうごございます。Tomonaritです。2025年はあまり投稿できなかったので、2026年はもう少し頑張ろうと思い、早速、今年最初の投稿を書いてみます。

ほぼ毎年のことなんですが、年初めは「今年の抱負」みたいなことを考えたりしませんか？私もそうなんですが、正直、そこまでスゴイ抱負とかって出てこないんです。んで、Chat GPTとの会話をしつつ、ふと以前から感じている疑問を質問したところ「なるほど」と思う答えが返ってきたので、それ書くことにしました。

私が以前から感じている疑問として、以下の点があります。

「ICT4Dの議論は批判的に課題を提示することばかりに注力しており、解決策の提示がかなり弱いと感じます。どうすれば解決策の議論が促進されるのでしょうか？」

特にここ最近、KanotとICT4D Labメンバーの岡崎さんと共にICT4D分野のレビュー論文執筆に取り組んでいるのですが、これまでのICT4D分野の論文をレビューしても、批判的な主張に注力しており、その解決策の提案になると、途端にトーンダウンしている感が否めません。批判的な主張の主だったものもは以下のようなものです。

• デジタル・ソリューションを導入すれば良いというテクノロジー中心主義に対する批判
• テクノロジーは既存の格差（経済力、社会的地位や権力、教育レベルなど）を拡大するという批判
• デジタル・ソリューションの多くは先進国の巨大IT企業が牛耳っているというデジタル植民地主義への批判
• 生成AIの活用は、先進国が先進国のロジック・文化で作ったアルゴリズムを途上国へ押し付けることになるという批判、などなど

どれもその通りだと納得感はあります。
他方、「では、どうしたらいいか？」というと、以下のような解決策が出てきます。

1. テクノロジー以外の政治・経済・社会・文化・環境・組織・リソース・ユーザーなど、幅広い要素を考慮してプロジェクトをデザインしていくべき（マンチェスター大学Heeks教授のオニオンリングモデルなど）
2. テクノロジーができるのは人々の既存の能力の増幅である点を踏まえてプロジェクトをデザインしていくべき（ミシガン大学の外山健太郎教授が提唱するAmplification Theoryなど）
3. 先進国の巨大IT企業のサービスでなく、その国独自のサービスを開発していこう（例えば、エチオピアならアムハラ語特化の生成AIとか）（Kanotの朝日新聞への投稿でも同様の示唆がありました）

これもその通りだと納得感はあります。
ただ、解決策として「じゃ、具体的にはどうすればいいの？」という問いが出てきてスッキリ感がイマイチなんです。これは特に私が、2008年にマンチェスター大学でICT4Dを勉強した頃から大きく変わっていない・・・というのが背景にあります。上記の1や2や3はその頃に主張されていた話なので進歩がないような気になってしまうのです（３については、当時は生成AIの話はなかったですが、ケニアのM-Pesaが登場した頃で「流石、現地ニーズに根差した現地発のソリューション！」という話はありました）。

そこで、上記の質問をChat GPTにしてみたのでした。その回答がなかなか良かったので忘れないように書いておこうと思います。

ICT4Dの議論は批判的に課題を提示することばかりに注力しており、解決策の提示がかなり弱いと感じます。どうすれば解決策の議論が促進されるのでしょうか？

まず、質問に対してこんな出だし回答が・・・。

とても重要で、しかもICT4D分野の核心を突く問いです。
結論から言うと、解決策が弱いのは研究者の怠慢ではなく、分野の「知の設計」がそうなっているからです。したがって必要なのは「もっと解決策を書こう」ではなく、解決策が“生まれやすくなる条件”を制度的・方法論的に整えることです。

な、なるほど。「知の設計」がそうなっているのか、、、と分かったようなわからないような用語が出てきたのですが、詳細を読むと納得感がありました。簡単に言うといかのようなことです。

なぜICT4Dは「批判は強く、処方は弱い」のか

• 批判は論文内で完結でき誤りが証明されにくいので主張しやすいが、解決策はそれが現場で検証される可能性があり失敗したときに責任を負うリスクがある。
• 技術は数年単位で更新されるので具体的な処方を提示するとすぐに「時代遅れ」になりやすい。
• ICT4D分野は過去の失敗から「一般解は危険だ」という強いアレルギーをもっているので「万能処方」を避ける傾向にあり解決策は超ローカルになるか、曖昧な抽象論になるか、になりがち。

では、解決策の議論を促進するための5つの転換をしよう

転換①「解決策＝最適解」という思い込みを捨てる：「 解決策 = 正しい答え」と思いがちですが、そうではなく、「解決策＝選択肢の構造化」と捉え、「Aが唯一の正解」ではなく、「Bを選ぶと何が得られ、何を失うか？」や「Bを選ぶと誰が不利になるか」といったトレードオフの可視化が解決策の第一歩。

転換②「設計原則（Design Principles）」に昇華する：ICT4Dで最も成功している処方は、具体策ではなく原則であり、例えば、「完全自動化よりも、人間による例外介入余地を残す」、「（AIで補助金受給者を選別するようなシステムの場合）精度向上より、異議申し立て可能性を優先する」みたいなこと。この方法なら、独自のコンテクストを尊重できたり、将来新たな技術が出てきたときにも耐えられる解決策になりえる。

転換③「失敗込みの処方」を書く：解決策が弱く見える最大の理由は、失敗が書かれていないことであり、有効なのは、「この解決策は以下の条件下では失敗する」、「実装能力が低い国家では逆効果になる」という失敗する条件も提示さすること。これは批判ではなく、成熟した処方。

転換④「誰が実行できるか」を明示する：多くの処方は暗黙に「全能な政府」を想定してるが、解決策を現実化するには、国家（中央／地方）、ドナー、国際機関、民間、市民社会、どのアクターに、どこまでの能力を要求するのかを明示する必要がある。

転換⑤「間違えても引き返せる解決策」を提案する：誰もが「間違った解決策を提示してしまうこと」を恐れるあまり、批判重視で処方が弱い・・・となる。そこで本当に必要なのは、間違えても引き返せる解決策である。例えば、段階的導入、人間の介在、異議申し立て、ロールバック可能性、といった可逆性の設計こそが、批判と処方をつなぐ橋となる。

実際のChat GTPからの回答はちょっと異なるのですが、個人的な思いも入れてこんな感じの５点にまとめてみした。転換②と④は、正直真新しい観点というよりは「だよなぁ」と感じましたが、転換①、③、⑤は自分的に結構良い気づきでした。私自身がまさに「批判は強く、処方は弱い」タイプなので、今後はこの５点を意識していこうと思います。

と、こんなことをやりながら、今年の目標は「生成AIをうまく使いこなす」にしようかと思い、サムネは午年にちなんでChat GPTに作ってもらいました。