現在は2026年1月28日、水曜日の夜です。
昨日、CZONをGBに売り込みました。GBは興味を示しましたが、OpenAI APIを呼び出す際にHTTP Proxyが必要な問題に直面していました。しかし、これまでのCZONはHTTP Proxyをサポートしていなかったため、今日は時間をかけてCZONにHTTP Proxyのサポート機能を追加しました。GBからのさらなるフィードバックを待っています。
GBは、C1に続く2人目のCZONユーザーです。私はCZONの実用化状況をテストする準備をしています。この段階では焦らず、着実に進めることが重要です。まずは初期ユーザーの体験を向上させ、一定のユーザーベースができてから、大規模なプロモーションを検討すべきです。
現在のCZONのワークフローは、ややぎこちない部分があります。私は、GitHub Actionsを完全に活用してCZONのワークフローを実現することを検討しています。つまり、ユーザーがコンテンツのソースファイルをメインブランチにプッシュすると、GitHub Actionsが自動的にCZONの実行をトリガーし、結果を直接メインブランチにプッシュする（またはプルリクエストを作成する）方式です。ただし、これにはGitHub Secretsを設定してOpenAI APIキーなどを保存する必要があります。この方法により、ユーザーがローカルでCZONを実行する手間が省け、使用のハードルを下げることができます。（もちろん、これはまだCZONEのような完全にハードルのない方式には至っていないため、これらの最適化を行うべきかどうか悩んでいます）
CZONEは、完全にハードルのない製品として位置づけられています。ユーザーはGitHubでアカウントを作成し、GitHub OAuthを通じてCZONEにログインするだけで、コンテンツサイトの作成、執筆、静的サイトの公開を直接行うことができます。他の場所に移動する必要は一切ありません。モバイル端末での編集体験は、SNSの投稿やツイートと同様に、非常にシンプルで直感的です。デスクトップでの編集体験は、NotionやTyporaのようなWYSIWYGエディターに似ています。ユーザーはコンテンツ作成に集中でき、他のすべての作業はCZONEが処理します。CZONEの利点は、MarkdownとGitを基盤としているため、ユーザーのデータは完全にユーザー自身のものとなり、いつでもデータをエクスポートしたり、他のプラットフォームに移行したりできる点です。これはWeb3の精神に合致しています。
もし今日GBがCZONではなくCZONEを使用していたなら、HTTP Proxyの問題をまったく考慮する必要はなかったでしょう。
私は、CZONの実用化状況をテストするために、さらに数名のユーザーを追加すべきだと考えています。
