未分類

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オンデマンドで仕入れるのは、あくまで情報です。 興味が惹かれる情報を見つけたら、図書館で実際に本を借りるなどして情報を知識に変えています。 大学の図書館はリクエストが無料でできるので、とても助かっています。 まとめ 視座を上げるためには、他の分野の情報を取り入れることが大切だと思います。 中でも今回は、動画で情報を取り入れることができるコンテンツを紹介しました。 紹介しきれなかったコンテンツがたくさんあり、今後また更新すると思います。 以上、理系におすすめしたい文系コンテンツでした。

本記事について 以下は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スキーマ、クライアント、サーバーなどのコンポーネントを作成できるため、クラスター内にさまざまなバージョンが共存します。...