Posts

1年半前、プロダクトを作りたくて会社を立ち上げた。現在、その会社の売上の中心は受託だ。 この記事では、なぜそうなったのか、受託を通じて何が見えるようになったのかを書く。 起業の成功談でも、受託への転向を正当化する話でもない。 まだプロダクト企業を目指している途中の記録である。 最初の1年で、売上は作れなかった 1年半前の大学生の頃、自分たちのプロダクトを作るために小さなAI企業を立ち上げた。 情報系の大学で学んでいたこともあり、技術にはある程度自信があった。 AIを使えば、資金のない少人数の会社でもソフトウェアのプロダクトは作れる。 実際に動くものを作り、ユーザーに使ってもらうところまでは、できた。 会社を作った最初の1年は、ほとんどの時間を開発に使った。 作りたいものを作り、改善し、使ってもらう。 反応があると、少しずつ事業になっているような気もした。 しかし結局のところ、会社を維持できるほどの売上は作れなかった。 一時期、銀行の口座残高は3,639円になったこともある。 誰が使うのかは何となく分かっていても、誰がその費用を払うのかは曖昧だった。 どの問題を、いくらで解決するのかも決めきれていなかった。 プロダクトを作ることと、プロダクトを売ることは、かなり違う。 今から考えれば当たり前だが、当時は作ることに意識が偏っていた。 使ってくれる人がいれば、その延長線上に売上もあるように感じていた。 現実には、利用者がいても、お金を払う人がいなければ事業にはならない。 そうしているうちに、開発を続けるための資金もなくなった。 あまりに生々しい圧倒的な現実のため、ここには書けないが、 資金の他にも、人間の地獄を見た。 そして、この地獄は、まだ序の口のように感じている。 会社を続けるために、受託を始めた 今年から、会社を続けるために受託の仕事を始めた。 企業向けの技術支援だ。 受託によって、最初の1年よりも会社を維持するための資金を確保しやすくなった。 とはいえ、プロダクト企業になれたわけではない。 売上の中心は受託だ。 案件を受注し、顧客ごとに必要なものを考え、開発や支援を行い、その対価を受け取る。 同じものを複数の顧客に継続して販売する仕組みは、まだ作れていない。 プロダクトを作るために会社を始めた。 そのプロダクトでは売上を作れず、会社を維持するために受託を始めた。 そして今は、受託を続けながら、もう一度プロダクトを作ろうとしている。 技術として動くことの他にも、大事な部分がある 受託を始めて良かったことの一つは、技術と現場との距離が縮まったことだ。 大学にいた頃は、技術的に何ができるかを考えることが中心だった。 受託では、まず顧客が何に困っているのかを聞く。 そのうえで、何を作るのか、いくらで引き受けるのか、いつまでに完成させるのかを決める。 学生が立ち上げた小さな会社でも、顧客の問題を解決できれば、さまざまな組織と仕事をする機会はある。 少なくとも私が関わった案件では、年齢や経歴だけで判断されることはなかった。 課題を理解しているか、提案に納得感があるか、本当に実行できそうか。見られていたのはそういう点だった。 一方で、技術として動くものを作れても、実際に導入されるとは限らない。 精度の高いモデルを作る。応答速度を改善する。デモを問題なく動かす。 開発側から見れば、それだけでもかなり大変だ。 しかし顧客は、それで導入を決める訳ではない。 導入によって何時間の業務を減らせるのか。 既存のシステムと安全に接続できるのか。 担当者が変わっても運用を続けられるのか。 費用をかけるだけの効果があるのか。 技術以外にも、決めなければならないことがいくつもある。 コードが正しく動くだけでは足りない。 その技術によって業務がどう変わり、導入する側がどのような責任を負うのかまで考える必要がある。 これは、プロダクトだけを作っていた最初の1年には、ほとんど見えていなかった。 コードを書かない時間が増えた 受託を始めると、技術以外の仕事も増える。 顧客との打ち合わせ、営業、見積もり、契約、納期の管理、請求、入金確認、会計、資金繰り。 協力者に仕事を頼む場合は、役割や報酬、成果物についても決めなければならない。 会社を始める前に想像していたより、コードを書かない時間はかなり多くなった。 情報系の人が全員、こうした仕事を経験した方がよいとは思わない。 企業や研究機関で技術に集中し、専門性を深める進路もある。 仕事とは別に、OSSや個人開発を続けることもできる。 起業とは異なる形で技術を追求する道は、いくつもある。 私の場合は、自分たちのプロダクトを事業として提供したいと考えたため、技術以外の部分にも関わる必要があった。 AIによって、資料作成や調査、契約書の確認などは以前より進めやすくなった。 それでも、誰の問題を扱うのか、いくらで引き受けるのか、どこまで責任を持つのかは、自分で判断するしかない。 会社を作るのは簡単でも、やめるのは簡単ではなかった 会社を作って半年ほど経った頃、真剣に、一度やめようと考えたことがある。 売上がほとんどなく、開発を続ける資金もなかった。 このまま続けるより畳んだ方がよいのではないかと思い、会社を終わらせる方法を調べた。...

2025年を振り返る 2025年は、キャリア的には 会社を作った LayerXのAi WorkforceのFDEチームにバイトで参加した キャパが足りず大学の単位を落としすぎて、留年が確定した という、個人的には大転換となった年だった。 一応、AI・LLMの進展を色々と考えた上で、このキャリア的な選択をしている。 というのもあるが、自分の作ったソフトウェアを多くの人に使ってほしい、 という欲望に実直に向き合っている結果でもある。 会社では、多くの人との出会いがあった。 会社を作ってソフトウェアを作っているというだけで、これだけ色々な人と出会い、 関わることができるのだから、本当にすごい。 出会いを求めているわけではないのだけど、何らかの目的のために行動した結果、 途中で色々な人と出会っていく。 そして、その旅の目的は大事なんだけど、その旅路がかけがえの無いものだったりする。 まるでフリーレンの冒険みたいだ。 今年は、初めて、きちんとソフトウェアを作って世の中に提供し始めた年だった。 MCP RouterをGitHubで公開後、1.5kのスターを集めて、WAUが数千人いる。 今年は、初めて、大人の世界を経験した年だった。 詳しくは書かないけど、生存と繁栄のためには汚いやり方でさえ正当化される、 そんな状況を目の当たりにした年だった。 「のほほん」と生きてたいけど、それは護られた環境で許される最高の贅沢なのだということ。 音楽 トップアーティストは ずとまよ ヨルシカ 羊文学 だった。 今年はクラシックを、あまり聴かなかった。 本 今年読んだ本の中で、良かったな、と思った本はこんなところ。 会社という迷宮 ゼロトゥワン ポジショニング戦略 今年は、あまり本を読めなかった。 ビジネス書かエンジニア関連書が多かった。 来年は、本をたくさん読める時間を作りたいな。 来年の抱負 世界を回って、世界を知りたい。 事業を、もっと伸ばしたい。 もっと、人間として強くなりたい。

こんにちは。 お久しぶりです。 最近はLLMのアプリケーションをいくつか作り始めました。 LLMとは全く関係がありませんが、理系の人におすすめしたい文系のコンテンツを紹介したいと思います。 「理系の人に」と銘打ってますが、それは私が理系のためで、理系以外の人にもおすすめです。 紹介しきれないコンテンツもあります。 NHKオンデマンド やはりNHKはクオリティが高いです。 その一方で、プロパガンダが結構入ってるなーとも思います（特にNHKスペシャル/映像の世紀バタフライエフェクトなど）。 100分de名著 日曜美術館 フロンティア ３か月でマスターする世界史 英雄たちの選択 映像の世紀 ＮＨＫスペシャル エンタメ系 プロフェッショナル　仕事の流儀 ねほりんぱほりん 偉人の年収　Ｈｏｗ　ｍｕｃｈ？ ドラマ 仮想儀礼 仕事の流儀は仕事が嫌な時に見ると、やる気が起きます。 YouTubeチャンネル YouTubeは個人制作が多いので、情報に偏りがあったりよく分からない意見が入ってたりします。 そういった部分も魅力だと思うので、暇だなーと思ったときに冗談半分で見てます。 公民ちゃんねる 哲学チャンネル アーカイブ社会学講義 脱構築研究会 Association for Deconstruction 【文学ミュージアム】LITERARY MUSEUM tekumuse 名著解説ラジオ(名著・解説猫) 創造編集社社会学哲学 帰ってきたロシュフコー MIT Architecture 図書館 YouTubeチャンネルやNHKオンデマンドで仕入れるのは、あくまで情報です。 興味が惹かれる情報を見つけたら、図書館で実際に本を借りるなどして情報を知識に変えています。 大学の図書館はリクエストが無料でできるので、とても助かっています。 まとめ 視座を上げるためには、他の分野の情報を取り入れることが大切だと思います。 中でも今回は、動画で情報を取り入れることができるコンテンツを紹介しました。 紹介しきれなかったコンテンツがたくさんあり、今後また更新すると思います。 以上、理系におすすめしたい文系コンテンツでした。

この記事について Decentralized SSOはすっごく前に作った作品ですが、それにZK（Zero Knowledge Proof）を追加したプロトコルを作りました。 この記事では、そのプロコトル制作の背景やプロコトルについて書きます。 正直、プロトコルと言うほど崇高なものではないですが、便宜上そう言ってます。 Zero Knowledge SSOに行き着くまで 前まではZKの意義深さがよく分からずにスルーしていたのですが、今年（2024年）の7月にZKの重要性を理解しました。 これは回路を書いたりと手を動かしてみたことが大きいと思います。 ZKの数学は難しいのですが、有用なライブラリ多いため実際に手を動かす分には数学無しでも扱えるようになっています。 そこからアプリケーションでもっとZKが使われて欲しい！との思いから、数学なしでZKのアプリケーションを作るための記事を書いたりしていました。 さて、それが一段落したところで、ZKを使ってSSOできないかな、と思い立ちました。 というのも、以前に作っていたDecentralized SSOでの課題を解決できそうな気がしたためです。 Decentralized SSOでは複数のIdPからユーザの信頼情報を取得しますが、その際に複数のサービス間で同一のアイデンティティを利用するためアイデンティティが紐づくというプライバシー上の懸念がありました。 そこでZKを使うことで、ユーザの信頼情報のみを取得し、アイデンティティを紐付けないでSSOを実現できるのではないか、と考えました。 色々と調べていくうちに、Ethereum財団のPSE（Privacy and Scaling Explorations）がSemaphoreというアイデンティティ関連のライブラリを作っていたため、それを利用することにしました。 また、PSEがAcceleration Programというタスクにお金を払うプログラムをやっていたため、それに応募できそうだと思いました。 ということで、１週間程度で雑にプロトタイプと仕様を作り、それを提出しました。 PSEの人がレビューをした後、今ちょうどスマホの鍵管理アプリを作っているプロジェクトがあって、それと統合したらどうだろうか？と言われました。 スマホアプリで実際に実現が出来そうだったので、それに同意してそのプロジェクトが完了するのを待っている最中です（2024/10/07 現在）。 待ち続けて2ヶ月以上経つので、一旦アウトプットとして書いておきます。 なお、以下はEthResearchにも投稿した内容の日本語版です。 プロトコル 概要 Anoidenは、ゼロ知識証明を用いた匿名シングルサインオンプロトコルです。このプロトコルは、アイデンティティプロバイダー（IdP）とサービスプロバイダー（SP）が共謀しても、ユーザのアイデンティティを秘密に保ちながらIdPからの情報を使ってSPへのサインインを可能にします。これはSemaphoreライブラリを利用します。 Connect ユーザは、IdPが指定する方法（Eメールや電話番号の登録など）でアカウントを作成し、ゼロ知識証明の鍵と接続します。 Auth SPはIdPを信頼しており、認証のエンドポイントを知っています。ユーザはSPに対してIdPでのログインを要求し、ノンスを取得します。 その後、ユーザは自身のアイデンティティの証明を作成しIdPに送信します。IdPは証明を確認し、ユーザが正当であれば対応する署名を作成します。 用語 拡張機能: ブラウザ拡張機能（アプリでも可）で、ユーザの鍵管理や証明の作成等を行います。SPとIdPが結託してもアイデンティティが秘匿されるために必要です。 anoiden.js: ウェブサイトのクライアントに拡張機能と通信するためのインターフェイスを提供します。 アイデンティティプロバイダー（IdP）: ユーザの正当性の情報をSPに提供する主体です。 サービスプロバイダー（SP）: IdPから提供されるユーザの正当性を利用する主体です。 IdPへの登録（Connect） ユーザがIdPでアカウント登録を完了すると、そのアカウントと拡張機能側の鍵を連携できます。 この連携により、ユーザは今後、認証を要求された際にこのIdPを使用可能になります。 また、鍵を使って匿名でIdPにログインすることも可能になります。 IdPのクライアントはanoiden.jsを通じて、署名と公開鍵を取得します。 const {signature, publicKey} = await connect(serviceName, nonce); ここでserviceNameはIdPのサービス名で、鍵の管理に使用されます。 nonceは推測が不可能な文字列で、IdPのサーバサイドから取得します。 以下の図はIdPのクライアントがユーザの署名を取得するまでのフローです。 クライアントは取得した署名、公開鍵、ノンスをサーバに送信します。 サーバはセッションを確認し、そのユーザに対してそのノンスを発行したかを確認します。 有効であれば署名を検証し、identifier（公開鍵のposeidonハッシュ）を取得し、Merkle Treeにidentifierを追加し、追加後のMerkle Rootを保存します。 Authorize SPはIdPを利用する際、事前に利用することを伝えており、IdPからクライアントIDを受け取っていることとします。...

本記事について 以下はEthResearchに投稿したものの日本語訳です（機械翻訳を使ったため、誤訳が含まれる可能性があります）。 既存のウェブでは、ユーザは自分のデータを管理することが難しく、サービスにロックインされています。「ポータブルウェブ」は既存のウェブと並行して存在し、ユーザーにデータに対するより大きなコントロールを提供し選択の幅を広げることを目指しています。ポータブルウェブ上のアプリケーションは、主に公共インフラとしての役割を果たすものを想定しています。 本記事では、ポータブルウェブの核心的なアイデアを紹介します。その実現可能性に直接関係のない詳細な仕様は含まれていません。 要約 ハッカブル：ユーザーがウェブアプリケーションをカスタマイズできる クラスターは単一のアプリケーション単位を表します。 誰でもクラスターを作成でき、クラスター内では、クラスター作成者以外の主体が自分のクライアントを作成したり、サーバーを提供したり、APIスキーマを定義したり、マイグレーションスクリプトを書けます。 クライアントとサーバーは疎結合で、APIスキーマを通じて接続され、異なる開発者が独立して作成できます。 例えば、ユーザーは自分のニーズに合わせたカスタムUIを作成し、アプリケーションを使いやすくすることができます。また、自分でAPIスキーマを開発し、特定の機能を拡張するためのサーバーをホスティングすることも可能です。このように、ポータブルウェブでは、開発者だけでなく一般ユーザーもアプリケーションの進化に積極的に貢献できます。 データロックインなし：ユーザーが自分のデータをコントロールできる クライアントはユーザーのデータをキャッシュします。 APIスキーマに準拠したサーバーを使用することで、クライアントは異なるサーバー間でキャッシュされたデータを共有できます。 クライアント上のキャッシュデータは、マイグレーションスクリプトを使用して移行することも可能です。 クライアントはユーザーが送受信するデータをキャッシュしますが、このデータをユーザーが選択したサーバーに送信することで、分散的に管理されます。必要に応じて、ユーザーは自分のデータを他のサーバーに移行でき、特定の組織にデータがロックインされることを防ぎます。 クリプトネイティブ：インセンティブメカニズムとしてのクリプトエコノミクス ポータブルウェブでは、クラスター提供者がトークンを発行し、そのトークンへの実需を生むクラスターを提供することでインセンティブを得ます。 クラスター内のすべての支払いは、発行されたトークンで行われます。 新しい参加者の存在はクラスターの成長に貢献するため、元のクラスター提供者は彼らを排除しません。 Web2が独占や勝者総取りのゲームとして機能する一方で、ポータブルウェブは協調的で包摂的なアプローチを促進します。 背景 Web2 Web3コミュニティでは、Web2の問題点について広く議論されていますので、ここでは深く掘り下げません。しかし、強調しておきたいのは、Web2の問題の根本はそのアーキテクチャにあるということです。具体的には、ブラウザがターゲットのURLに直接アクセスする方式です。 Web2のアーキテクチャでは、ユーザーは自分が生成したコンテンツを所有権やローカルコピーを保持せずにサービスに直接投稿します。ユーザーのアカウントやコンテンツはサービス内に存在し、そのサービスがデータを蓄積します。この蓄積は新しいデータの生成を加速させます。ユーザーが別のサービスに移行して同じレベルの利便性を得ることは非常に困難です。そのためには、ユーザー自身がコンテンツを移行する必要があり、他のユーザーも大規模に移行する必要があります。 既存のウェブアーキテクチャは、コンテンツのロックインやアカウントのロックインを引き起こし、それが権力の集中や勝者総取りのダイナミクスを助長します。 Web3 Web3は既存の権力構造に挑戦し、ユーザーの権利を最大化するとしばしば主張されますが、実際には現在のところ、Web2の上にブロックチェーン層を追加しているに過ぎません。 ブロックチェーンは分散型ですが、既存のWeb3アプリケーションが現在のウェブアーキテクチャの上に構築されているという事実は、そのポテンシャルを損なっています。 ポータブルウェブのアーキテクチャ 上記の問題を解決し、ユーザーの権利を最大化しながら分散型のウェブを実現するためには、新しいアーキテクチャを構築する必要があります。その提案された解決策がポータブルウェブです。この新しいウェブアーキテクチャは、ユーザーが自分のデータとアイデンティティを完全にコントロールでき、開発者やサービス提供者が協力して単一のアプリケーションを進化させることを可能にします。 ポータブルウェブの構成要素 ポータブルウェブブラウザ ブラウザは、ポータブルウェブを実現するためにいくつかの重要な役割を果たします。 制御されたサーバー通信：クライアントが通信できるサーバーを制限します。ユーザーが明示的に意図しない限り、クライアントはサーバーとやり取りできません。 通貨の制限：アプリケーション内での支払いに使用される通貨を制限します。ブラウザにはウォレットが含まれており、支払いはクラスターで最初に設定された通貨でのみ行われます。デフォルトでは、ブラウザは内部の取引所（DEXまたはCEX）と連携しているため、ユーザーは使用されている通貨を意識しません。 アイデンティティ管理：ユーザーのアイデンティティを自己主権型アイデンティティ（SSI）として管理し、サーバーやクライアントがユーザーのアイデンティティをロックインすることを防ぎます。 ブートストラップのためのビルトインサポート：インデックスクラスター用のクライアントとサーバーの情報が内蔵されており、ブートストラップをサポートします。ユーザーは後で他のクライアントやサーバーに接続できます。 データ移行と更新：クライアントで指定されたマイグレーションスクリプトを実行してデータを転送し、クライアントの更新を管理します。 クラスター クラスターは、その目的ドキュメントによって識別される単一のアプリケーションを表します。 クラスターを構成する要素は次のとおりです： 目的ドキュメント APIスキーマ マイグレーションスクリプト クライアント サーバー 誰でも目的ドキュメント以外のコンポーネントを提供して、クラスターの開発と進化に貢献できます。 インデックスクラスター インデックスクラスターは、ポータブルウェブ内のApp Storeのような機能を果たします（誰でも提供可能です）。 クラスターのコンポーネントの提供者は、自分のデータをインデックスクラスターに登録します。インデックスクラスターはこの登録されたデータをホスティングし、ユーザーに情報やソフトウェアを提供します。また、その情報にはバージョンや互換性などの情報も含まれます。 インデックスクラスターは、どのコンポーネントがどのクラスターに属しているかを知っており、サーバーとAPIスキーマ、クライアントとAPIスキーマ、クライアントとマイグレーションスクリプトの関係を理解しています。 クラスターの構成要素 目的ドキュメント 目的ドキュメントは、コミュニティ主導の開発を可能にし、促進するためのものです。これには以下が定義されています： 究極の目標：クラスターが達成しようとする包括的な目標。 使用されるトークン：クラスター内で利用される特定のトークン。 このドキュメントはクラスターの作成時に公開され、その後は不変のままです。目的ドキュメントに記載された究極の目標はシステム的な機能を持ちませんが、コミュニティはこのドキュメントを基に機能の改善や追加を行います。 APIスキーマ APIスキーマは、クライアントとサーバー間の通信方法を定義するプロトコルです。これは開発者が読める形式である必要があります。このスキーマに従うことで、異なる開発者が作成したクライアントとサーバーが相互に通信できます。 APIスキーマ間の互換性がある場合、サーバーとクライアントは複数のWeb APIスキーマをサポートできます。 マイグレーションスクリプト マイグレーションスクリプトは、クライアントが特定のデータモデルを持つことを前提としています。これにより、同じマイグレーションスクリプトを参照するクライアント間でのデータ移行と同期が可能になります。 クライアント クライアントは、HTMLやJavaScriptなどの静的コンテンツで構成されており、特定のインターネット接続や特定のサーバーに依存せずに独立して動作できます。クライアントは、ユーザーが指定した宛先としか通信できません。特定のサーバーに依存するように実装してはいけません。 クライアントは、ユーザーがサーバーに送信またはサーバーから受信するデータをキャッシュできます。特定のマイグレーションスクリプトを指定し、そのスクリプトを実行することでデータ移行が可能なデータ構造でデータをキャッシュしなければなりません。 サーバー サーバーは、APIスキーマに準拠したAPIを提供します。APIスキーマで定義できるあらゆる機能を提供できます。 バージョン管理 ポータブルウェブでは、クラスターは単一のアプリケーション単位ですが、使用するコンポーネントによって異なる動作をします。誰でもマイグレーションスクリプト、APIスキーマ、クライアント、サーバーなどのコンポーネントを作成できるため、クラスター内にさまざまなバージョンが共存します。...

はじめに 安冨歩さんという方がいらっしゃいます。 私は大学生になって間もない頃、図書館で「経済学の船出」を読み、こんな経済学者がいるのかと衝撃を受けたのですが、今日はそんな経済学者が作った貨幣の生成や崩壊のMAS（マルチエージェントシミュレーション）モデルを紹介します。 モデル自体は1995年に論文「The emergence and collapse of money」で発表され、2000年には書籍として「貨幣の複雑性: 生成と崩壊の理論」（以降、書籍）が出版されています（書籍は出版社が潰れたため現在は中古市場で高値取引されています）。 モデルは拡張性が高く、暗号通貨や基軸通貨の分析などの研究でベースとして現在も利用されています（応用例は別記事で紹介します）。 モデルは3種類ありますが、いずれも人工的な市場（しじょう）というよりも人工的な市場（いちば）に近いモデルです。 3つのモデルから、段階的に貨幣の生成や崩壊の設定を探っています。 最終的なモデル（進化的モデル）ではエージェントのシンプルな行動ルール（欲求、需要、生産、消費、情報交換、戦略の変更）から貨幣の生成や崩壊という複雑な現象を再現しています。 ここでは基本的に書籍を参照して、モデルのみを紹介します（背景の思想等については別の記事で紹介します）。 詳細を知りたい方は書籍をあたってください。 モデルの種類 書籍では、 物々交換のモデル（欲望の二重一致の困難さを確認） 貨幣的交換のモデル（貨幣の生成メカニズムを確認） 進化的モデル（貨幣の生成と崩壊メカニズムを確認） という順序で発展的にモデルを作成しています。 以下、それぞれについて紹介します。 共通する設定 その前にモデルで共通する設定を紹介します。 1ターンで全てのエージェントはそれぞれ1回ずつ需要→交換→消費・生産のサイクルを実行する あるエージェントが生産する商品は1種類で、シミュレーションの途中でエージェントが生産する商品は変化しない エージェントは、最初に自分が生産した商品を1つ所有している 各エージェントは最初に自分が欲求する商品を決める エージェントは、自分が生産した商品は欲求しない エージェントは以下のパラメータを持ちます。 $$Agent_i = (w_i, p_i, \boldsymbol{h_i}, \boldsymbol{d_i}, u_i)$$ $w$ - 欲求する商品：エージェントが消費したい対象で、所有する場合は消費ステップで全て消費する $p$ - 生産する商品：エージェントが生産する商品 $\boldsymbol{h}$ - 所有ベクトル：エージェントが持っている商品のベクトル $\boldsymbol{d}$ - 需要ベクトル：エージェントが消費したいと考えているかに関わらず需要している商品のベクトル $u$ - 効用水準：所有している$w$を消費して増加する、エージェントの得点 ここで、欲求と需要を区別していることに注意します。 また、シミュレーションには以下のパラメータがあります。 $N$ - エージェント数 $C$ - 所有費（書籍では運送費ですが、モデルは距離的なロジックを持たないため所有としています） $P$ - 生産費 物々交換モデル パラメータ 書籍では、以下のパラメータが使用されています。 $N = 50$ $C = 0....

はじめに この記事は、現状のWebアーキテクチャの問題点を示し、それを解決せんとするムーブメントをまとめたものです。 私はPortable WebというWebアーキテクチャを作りましたが、本稿はPortable Webを説明するための序章として書きます。 そのため、本ブログの他の整理記事とは多少異なります（独自の解釈があったり、オピニオンが入っていたりします）。 既存のWebアーキテクチャに対する問題意識と目標 イントロ:「ElonMuskが狂ったらどうなる？」 Twitterは数億人が利用するWebサービスですが、そのWebサービスの命運がたった１人によって握られているというのは異常な事態と言えるでしょう。 しかし、社会はTwitterが使いやすいという理由でTwitterを捨てません。 社会はTwitterに依存してしまっているのです。 ElonMuskがTwitterを買収してから、次世代Webの必要性を世間の人々が納得してくれ易くなりました。 次世代Webの必要性が伝わるために実際にWebが崩壊していくことが必要であるというのは、とても皮肉なことで、最近は喜ばしいのか悲しいのかよく分からない気持ちになります。 例えるなら、システムが攻撃された後にセキュリティ対策を施すようなものです。 ここで私は説明の簡易性のためにElonMuskを例に出している　―Twitterを媒介（メディア）としている―　だけであって、Twitterに限らずWeb全体がこのような状況です。 Web全体、つまり現状のWebアーキテクチャに問題があるです。 本稿では、その問題と解決策を考えていきます。 コラム：単一の主体 ここでの単一の主体とは、個人のみならず株式会社やDAO（Decentralized Autonomous Organization）を含みます。 というのは、株式会社やDAOであっても、最終的に投票などによって意思決定はA/Bのどちらか１つに決まるためです。 複数の主体というのは、互いに独立に外部に影響を与える、複数の意思決定者です。 主体の数は、その主体の内部的な意思決定構造には関係なく、外部に影響を与える意思決定者の数です。 例えばタケノコとキノコがあった時に、ある個人がタケノコを選んだことと、ある会社がタケノコを選んだことは場からタケノコが１つ減ったという点では同じです。 Web2の問題点、それは解決できるか 現在のWebアーキテクチャ（Web1~Web2）におけるWebサービスは「単一の主体が提供する、ブラウザを通じてアクセスできるアプリケーション」と定義できます。 さらにアプリケーションは、「何らかの目的を持った機能の集合体」と定義できます。 例えばFacebookは１つのWebサービスであり、単一の提供者はMeta社です。 しかし、新しい技術（Fediverse等）の登場によって、必ずしもこの定義が当てはまらくなってきています。 つまり、Webサービスが進化しているのです。 本稿では、後で新たにWebサービスを定義しますが、それまでは上の定義を利用します。 Web2の問題点は、利用者、延いては社会がWebサービスに依存してしまっていることです。 その原因としてデータロックインがあります。 なぜWebサービスがデータロックインするかというと、利用者の流出を防ぎたいためです。 利用者数が収益に直結することを考えるとそのような戦略になるのが自然だと思います。 例えば、毎日Facebookの投稿をしたり、いいね！を押したり、知り合いと繋がりを持ったとして、それを数年繰り返すと膨大な量のデータになります。 Webサービスを乗り換える際はそれらのコンテンツを移行することに加えて、全ての知り合いが同時に乗り換えてくれなければ、移行先のWebサービスの効用は減ります。 全ての知り合いが一斉に乗り換えるというのは理論上は可能でも現実的に不可能であって、それ故にデータロックインは強さを持つし、利用者はWebサービスに依存してしまうのです。 ただし、もしデータが一部しか移行できないとしても移行先のWebサービスの効用が高いという（とても珍しい）状況では、利用者は依存を振り切って移行するでしょう。 さて、Webサービスへの依存は利用者にとって悪い（ここでの「悪」は、あくまでも私の考える「悪」です）ことでしょうか？ 上述の定義では、悪いことになります。 というのも、単一の主体が提供するものとして定義されているため、Webサービスの利用者はその単一の主体に隷属してしまうためです。 実際、Twitterに生息している感受性の高いネットユーザーはElonMuskに隷属している　―ElonMuskの意思決定次第でアカウントがBANされる可能性もある（実際に起きている）し、目に触れるツイートも違ってくる（つまり考えに影響を及ぼす）―　と感じるのではないのでしょうか。 もし単一のWebサービスが複数の主体から提供されている場合、利用者には提供者を選択する自由があり、それによって提供者に対する隷属から逃れられるかもしれません（私は逃れられると考えています）。 したがって、Webサービスに依存することが悪いというより、むしろWebサービスを提供する主体に依存することが悪いのです。 この悪（=提供者への隷属）を解決するための動向としては、「体制による反体制的な活動」と「無名の人々による反体制的な活動」に大別できます。 前者は、例えばEUのデジタル市場法（後述します）があります。 法律は自律した国民が選出した代理者が強制力のある法律を制定することによって、強制的に社会を変革するという発想です。 後者はというと、例えばFediverse（後述します）などの新たなアーキテクチャです。 アーキテクチャは、技術者（自律した個人・組織）が新たなシステムを作り、それが人々にとってより良いものであるなら、自然とそのシステムに移り変わるだろうという発想です。 私はアーキテクチャの観点から考えています。 法律は施行された時から社会に対し強制力を持ちますが、アーキテクチャは社会に対しオプション（選択可能性が確保される）になります。 そのため、できることならアーキテクチャの方が良いと考えます。 しかし、アーキテクチャで独占を変えられない地点まで行ってしまった場合は法律を作る正当性があると考えます。 理想（目的）は、利用者がWebサービスの提供者に隷属している状態から脱却し、ある提供者の一存で利用者が右往左往されるのではなく、Webサービスの主権を利用者が持つことです。 そのためには、誰でも提供者になることができ、かつ利用者が提供者を自由に選択できることが必要です。 ここでの「自由に」というのは、利用者が乗り換える際に、その乗り換え先から同等以上の効用を得ることができるということです。 データを伴わない移行などで、効用が下がった場合、それは不自由な選択です。 例えるなら、居場所のない女性がDV彼氏に依存してしまう状況から、たくさんの男性がその女性にアプローチする状況が生まれ、より大切に扱ってくれる男性の所へ行くという感覚です。 したがって、依存の原因であるデータロックインを回避し、誰でも特定のWebサービスを提供でき、かつ利用者（社会）が特定のWebサービス提供者に依存しないWebアーキテクチャを構築するのが目標になります。 コラム：法律とアーキテクチャ 法律とアーキテクチャの関係についてさらに詳しく知りたい方には、アーキテクチャと法がオススメです。 数年前に興味で購入しました。 読みやすいため、今でもたまに気軽に開きます。 買ってよかったと思える書籍です。...

はじめに みなさん、良い文章書いてますか？ 私自身、良い文章を書くにはどうしたら良いのだろうとか、そもそも良い文章とは何だろうと思う事が多々あります。 本稿は、図書館にあった「文章の書き方」的な本を数冊読んで、良さそうな項目を抽出して自分なりの言葉でまとめたものです。 良さそうな項目というのは、複数の本に書いてある項目や直感（経験を含む）的に良いと思った項目です。 読んだ本は最後にある参考文献にまとめてます。 本稿は「本→ノートに１ページでまとめる→記事」という流れで書いているため、不完全な場合があります。 本稿は良い文章を書くための方法を、いつでもサッと見返せるように整理することを目的としています。 ここでの良い文章とは、読者にあまり負担をかけず、何かを論理的にハッキリと伝えられるものを指します。 文章以前の心構え 良い文章を書くために必要な心構えとして、次のようなものがあります。 情報は「分かりやすさ」でラッピングして相手に届けなければいけない メンタルモデルを意識する 書いて良いのは事実と意見のみ。お気持ち表明はTwitterでどうぞ ハッキリと伝える 伝えるために必要十分な情報を書く 情報はどんなに有益だろうと、相手に伝わらなくては意味がありません。 絶えず情報爆発し続ける現代では、たとえ相手に興味を持ってもらえたとしても相手に伝わらない文章は後回しにされ、読んでもらえない可能性が大きいです。 したがって、文章を書く際の最重要項目は分かりやすさです。 そして分かりやすさを作るには、誰を読者と想定するのか、読者の予備知識はどの程度か、読者は文章に何を期待・要求しているのか考え、それに適合させる必要があります。 文学的文章であれば表現としてまかり通ると思いますが、それ以外では構成や文体などを相手に合わせなければいけません。 文章が言わんとすることは、読者の短期記憶に収納されます。 人間の短期記憶には限りがあります。 もし最初に○○についての文章だと分かっていたら、読者は事前に関連する情報を活性化します。 メンタルモデルの構築に成功した場合、話が通じやすくなります。 というのは、読者と前提を共有できているためです。 逆に失敗した場合は新しい言語をその言語の原文のみで学ぶようなもので、単純なことを言っていても難解になります。 書いてよいのは事実と、そこから導かれる意見です。 根拠のない意見、すなわち心情を書いてはいけません。 心情を書いた瞬間、その文章はポエムになります。 また、事実と意見は峻別する必要があります。 もし事実と意見が混同されていれば、読者が混乱するどころか、その文章の信頼性は低下します。 日本語は曖昧な言語です。 例えば、主語を省略したり自分の意見なのに受動態を使ったりすることが多々あります。 読者に行間を読ませてはいけませんし、読んでもらえると考えて文章を書くのは楽観的すぎます。 私は以前まで行間に頼った文章を書いていました（楽観的すぎました）が、読者がよほど作者を好きであるか重要だと感じていない限り、行間なんて読んでもらえませんし、直接的に書いてある方が明瞭で分かりやすいです。 また論理的に何かを伝えるには、読者がどんな文章の読み方をしても誤読できないように書く必要があります。 もし文章の読み方次第で色々な解釈があると言えるなら、それは責任回避で、何か言っているようでほとんど何も言ってないのと同等です。 文章は目的があって書かれます。 目的のない文章は（人間が書くもののなかでは）ありません。 伝えるために必要な情報は書くべきですし、不要な情報は削るべきです。 では、書く作業をどのように進めたら必要十分な情報を書けるのでしょうか。 文章を書く際は１つの大きな目的を定め、その目的のための全体の骨格を作ります。 そして骨格が目的を達成するために必要充分であるかを熟考します。 骨格が完成したら、骨格の構成要素ごとの目標を達成するためだけに文章を書きます。 骨格の構成要素ごとの目標に不要な文章を書いてはいけませんし、論理が飛躍した文章や厚みのない文章を書いてもいけません。 コラム：起承転結 物語の伝え方に起承転結がありますが、この「転」は、何かを論理的に伝える文章に向きません。 起承と転があまりにも違いすぎて、読者が混乱してしまいます。 文章内での刺激的な変化は不要で、「あれ？もう終わっちゃったよ」程度が良いです。 パラグラフライティング パラグラフライティングは良い文章を書くのに最も最適な方法です。 パラグラフライティングとは、トピックセンテンスとサポーティングセンテンスによって構成される、世界で広く使われている書く技術です。 パラグラフライティングは以下のような特徴があります。 トピックセンテンスでパラグラフの要約、サポーティングセンテンスで詳細を記述 文章はパラグラフを最小単位として構成される １つのパラグラフで１つのメッセージを伝える 書いた内容が、それまでに書いてきた内容のみで理解できるよう構成する トピックセンテンスは、パラグラフの最初に一文でそのパラグラフの要約を書きます。 文書の各パラグラフのトピックセンテンスだけ読んで、どんな内容が書かれてあるか大まかに分かるのがベストです。 こうすることで、読者は飛ばし読みできます。 つまり読者が知っている内容を飛ばしたり、興味のある箇所だけつまみ食いできるようになります。 パラグラフライティングで書かれた文章は、文単位ではなくパラフラフ単位で構成されます。 文単位で構成された文章では、形式が変則的になりがちで、形式と論理のかたまりが必ずしも一致しません。 その結果、分かりにくくなります。 対してパラグラフが単位であれば、形式が決まっているため、読者は論理が掴みやすいです。 パラグラフは最小単位なので、メッセージは１つだけ伝えるようにしましょう。 １つのメッセージを伝えるためだけにそのパラグラフを書き、パラグラフを繋げることによって複数のメッセージを伝えるようにします。 パラグラフでは扱う話題+主張を１セットとしますが、主張が２つある場合は複数のパラグラフに区切ります。 つまり、（扱う話題+主張）+（扱う話題+主張）です。 また、パラグラフは３~８文にするべきです。 というのは、短すぎると単位が文となり、長すぎると読みにくいためです（長い場合は複数のメッセージが入っている可能性があります）。...

はじめに 私は以前作った作品に、共創のためのインセンティブ設計としてクリプトエコノミクスを組み込みました。 しかし今振り返ると、クリプトエコノミクスって何だっけ？となって混乱したので整理します。 クリプトエコノミクスが生まれたきっかけ（背景）、クリプトエコノミクスとは何であるかという大まかな流れでクリプトエコノミクスを整理します。 また、最後には私なりのクリプトエコノミクスを定義します（まとめ）。 詳細に入る前に、クリプトエコノミクスをざっと掴んでおきましょう。 ウィーン大学のShermin Voshmgirらは以下のような定義をしています。 インターネット上にある他の情報を鑑みても、この定義は一般的な定義となっていると思います。 Cryptoeconomics is an emerging field of economic coordination games in cryptographically secured peer-to-peer networks. Foundations of Cryptoeconomic Systems クリプトエコノミクスが生まれたきっかけ（背景） クリプトエコノミクスを理解するには、最初にクリプトエコノミクスが組み込まれたシステムがどのようなもので、どのような課題があったかを知るのが良い方法です。 ここでは最初にクリプトエコノミクスが組み込まれたシステムであるBitcoinの目的、それを実現する難しさ、その解決策を記します。 せっかちな方は、次の章まで飛ばして頂いても結構です。 Bitcoinの目的ですが、Bitcoin論文のIntroductionには、最初に以下のような記述があります。 Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model....

Decentralized SSO Decentralized SSOは、SSOを分権化することで、セキュリティを向上させる仕組み・ブラウザ拡張のソフトウェアです。 この作品は私が普通科の高校生だった頃（2020の春頃）に制作し、U-22プロコンBest40の評価を頂いた処女作（Best40程度では処女作に入らないかもしれませんが）です。 U-22には、Aoiという作品名で提出しています。 背景 皆さまご存じの通り、SSO(Single Sign On)はその利便性から、広く普及しています。 しかし広い意味でのセキュリティ的な懸念があります。 つまり、SSOを提供する主体（Trusted Party）が絶対的な権威となり、利用者の正当性を保障するということです。 SSOを利用する主体（Relying Party）は利用者の正当性を根拠なく信じます。 この正当性というのは、利用者がBotでないこと、利用者が本人であること、利用者が正当な目的で利用していることなどです。 一つ例を挙げましょう。 TwitterはSSOを提供しています。 もしElonMuskが狂ってしまい、TwitterのSSOでなんらかの不正な認証が行われるとしたら？ 世の中のサービスは大混乱です。 TrustedPartyが保障する利用者の正当性についての情報がより信頼できればRelying Party側はハッピーです。 では、どうすれば情報の信頼性が向上するのでしょうか？ 解決策 複数のTrusted Partyから利用者の正当性に関する情報を得ることが出来れば、情報の信頼性を高めることができます。 これが大きな方針です。 Decentralized SSOでは、利用者のアカウントを公開鍵として表現します。 Decentralized SSOの利用プロセスはシンプルで、次のようなものです。 利用者は、Decentralized SSOを利用するTrusted Partyにアクセスし、会員登録を行う。 利用者は、Trusted Partyの内部アカウントと拡張機能のアカウントを紐づけます。 利用者は、この1~2を他のTrusted Partyでも同様に行います。ただし、拡張機能側のアカウントは１つです。 そして、とあるRelying Partyを利用し始めるとき、その公開鍵利用してログインできます。 Relying Partyは自分が比較的信頼する複数のTrustedPartyから、利用者の公開鍵のハッシュ値をもとにして利用者の正当性を確認します。 これだけです。 これだけで、SSOの信頼性が向上します。 公開鍵を利用するということがポイントですね。 この方法の問題点 ただしこれにはいくつかの問題点があります。 公開鍵とサービス内部のアカウントを紐づけることで、より多くのサービスに渡って利用者がプロファイリングされる。 統一された規格を利用する必要があるが、標準化のID（ Internet Draft ）提出などを行っていない。 ただし、Metamaskなどのブラウザウォレットの普及によって、2020年ほど普及のハードルは高くないと思います。 これらの問題点が解決されることを願いつつ、私は今日も自分の興味に従い他の領域に足を踏み入れます。 いつかこの作品にひょっこり戻ってくるかもしれません。