goofmint 1.0.2 → 1.0.4

package/_posts/2026-01-15-bye-bye-ai-text-writer.md

@@ -0,0 +1,44 @@
+---
+layout: post
+title: "ライティングにはAIを適用しないことにしました"
+date: 2026-01-21 12:00:00 +0900
+lang: ja
+---
+
+プログラミングを覚え始めた当初からEmacsを使ってきたので、ライティングとコーディングは同じ環境（Emacs）で行うのが当たり前でした。文字書きに適したエディタが時々出てきて、それらを試したこともあるのだけれど、手には馴染みませんでした。
+
+2018年くらい（？）にEmacsからVS Codeに乗り換えて、ブログなどのライティングもVS Code上で行うようになっています。そして、2023年頃に現れたのがGitHub Copilotです。エンターキーを押すと、それっぽいコードをインテリジェンスに出してくれます。変数名の補完も、関数名も自在に保管してくれ、革命的に便利な機能でした。
+
+たぶん最初の頃はプログラミング言語に対してだけ有効だったはずなのですが、すぐにドキュメントにも補完が行われるようになりました。ちゃんと日本語で、こちらの気持ちを察して生成してくれる。素晴らしい！
+
+でも、それも先日まで。残念だけれど、Markdownに対してはGitHub Copilotは無効にしました。
+
+その要因は、生成AIによって自分の思考回路が引っ張られる感覚が強くなったからです。文章の書き方は人によって違うと思いますが、私の場合は割と雰囲気で書いているところが大きいです。徐々に書いていく中で言語化・解像度が上がって結論につながっていくイメージです。
+
+そうした書き方だと、長文の補完が出てきてそれを採用すると、自分の思考までぐっとそっち側に引きずられてしまいます。サジェストを数回採用すると、そもそも自分が書きたかった内容ではない「何か」になってしまっています。
+
+その感覚を覚えてから、GitHub Copilotに書かせるのはダメだと気づきました。ゼロから一を作る部分は自分で進めなければ、何の面白みもない空気みたいな文章が生まれてしまう気がします。
+
+もちろん、手作業で書くと時間がかかるし、支離滅裂な部分があったり、誤字もあるかもしれません。そうした時に最低限の編集をAIに任せるのは良いかもしれません。
+
+## AI向きのテキスト
+
+AIで作るドキュメントとして向いているものがあるとすれば、ある程度作成したソフトウェアのREADMEや、ドキュメントはいいと思います。ベースになるソフトウェアのコードはあるので、それを網羅的に調べてドキュメントを作ってくれるのはAI向きではないでしょうか。
+
+ブログはそうじゃなく、私の中にコンセプトがあって、それを吐き出す場です。そこにAIが絡むと若干の気持ち悪さがあるなぁと。
+
+## 英訳・日本語訳
+
+先日、zenn.devでブログ記事の自動英訳機能が炎上していました。
+
+[記事の英語版生成の実験的な提供を開始します（Beta） \| What's New in Zenn](https://info.zenn.dev/2026-01-09-translate-articles)
+
+デフォルト有効というのはよくなかったかも知れませんが、自動英訳自体はいいと思います。日本語の記事でとてもいい内容なのに、日本語であるためにグローバルに届いていないものがたくさんあるからです。
+
+たとえばCodeRabbitに関する日本語の記事を紹介したいと思った時に、それを英訳してからSlackで共有するのは面倒なんですよね。日本にいいエンジニアがいることをアピールしたいのに、日本語という言語が壁になってしまうのは非常に勿体無いと感じています。
+
+もちろん、誤訳があったり、どこからかいきなりツッコミが来るかも知れませんが、それも含めてコミュニケーションなんじゃないでしょうか。誤訳があっても自分が悪いわけではなく、zenn.dev側の問題ですし、0.001%の誤訳を恐れてグローバル発信を嫌がるのは勿体無いです。
+
+## まとめ
+
+ということで、この文章もAI味ゼロ%でお届けしました。

package/_posts/2026-01-24-future-of-saas.md

@@ -0,0 +1,93 @@
+---
+layout: post
+title: "個人開発の先にSaaSの未来が見えた話"
+date: 2026-01-24 12:00:00 +0900
+lang: ja
+---
+
+ずっと長いこと、タスク管理にTodoistを使っています。メールを見返してみたところ、2013年10月から使っているようです。つまり、かれこれ12年以上使っています。それまでタスク管理というのに失敗し続けてきて、はじめてうまく回るようになったのがTodoistでした。
+
+そんなTodoistでは、旧ビジネスプランのもっとも安価なものを使い続けており、年額3,500円でした。振り返ってみれば、すごく安いなと思うのですが、そんなTodoistではこのプランがなくなり、新しいビジネスプランが年額11,520円になります。個人用にはプロプランというのもあるのですが、こちらは月額672円（年額8,064円）になります。どちらを選ぼうが、2〜4倍近いコストアップになります。
+
+物価高になってきて、その中での値上げはやむを得ない場合もあるでしょう。しかし、この手のSaaSの値上げって、明らかにユーザーが期待していない機能追加に伴うものな気がしています。つまり、AIです。Todoistでも `Todoist Assist` なるAIアシスタントが出ているようです。はっきりいって、不要です。この結果として値上げになったとしたら、非常に残念なことです。
+
+よく知られているところではAdobeもそうです。Adobeのサブスクリプションは年々高額になっていますが、あれもAI機能の開発負担によるものが大きいように感じます。ユーザーの8割は、2割の機能も使わないと言いますが、PhotoshopとかIllustratorはまさにそうなんじゃないかと思ってしまいます。大半のユーザーにとって不要な機能が搭載され、その開発費用を支払うのはしんどいものがあります。
+
+## 自分で小さいツールを作る
+
+カレンダー自体はGoogleカレンダーに寄せている（Todoistでも連携機能を使っている）ので、これを機にタスク管理をGoogleカレンダーとGoogle Tasksに寄せることにしました。
+
+しかし、一点問題があります。それは、Todoistの超絶便利な機能である「自然言語によるタスク追加」が必要ということです。例えば「再来週月曜日 ミーティング #プロジェクトA \[3時間\]」みたいな自然言語に合わせたタスクの入力ができるのが便利なのです。似たような機能はmacOSのカレンダーのクイックイベントがあります。しかし、同じ機能はiOSにはありません。
+
+同じ機能がないと、タスクの入力やカレンダーへの予定登録が面倒になり、長続きしないことは明らかです。TodoistのOSS代替みたいのも探しましたが、やはり同様の機能を提供するものはありませんでした。
+
+そこで、自作することにしました。
+
+[goofmint/Text2Cal: Add schedule to your Google Calendar from natural language\.](https://github.com/goofmint/Text2Cal)
+
+Text2Calは、ごく小さなツールです。GoogleスプレッドシートのGoogle Apps Scriptで実行します。受け取ったテキストをChatGPTに投げて、予定入力用のJSONに変換します。
+
+`21日18:00 CodeRabbit User Group Tokyo #0`
+
+みたいな文字列を投げると、以下のようなJSONに展開します。
+
+```json
+{
+  "title": "CodeRabbit User Group Tokyo",
+  "start": "2026-01-21T18:00:00+09:00",
+  "end": "2026-01-21T19:00:00+09:00",
+  "location": null,
+  "label": "0",
+  "timezone": "Asia/Tokyo",
+  "recurrence": null
+}
+```
+
+これをGoogleカレンダーに登録する仕組みです。結果として、以下のようなJSONがGoogleカレンダーから返ってきます。
+
+```json
+{
+  "id": "l0g...udo",
+  "status": "confirmed",
+  "htmlLink": "https://www.google.com/calendar/event?eid=bDB...",
+  "colorId": "8"
+}
+```
+
+入力テキストの頭に `!` を入れると、Google Tasksにデータを登録します。 `!今日 請求書` みたいなテキストを入力する形です。
+
+あとは、macOS/iOSのショートカットを作って、入力文字列をText2CalのWebアプリケーションに送信するだけです。Googleスプレッドシートを使っているのは、入力した内容や結果をログとして残せること、GoogleカレンダーやGoogle Tasks APIを簡単に使えるためです。
+
+たったこれだけで、個人的に本質的に必要だった機能ができてしまい、Todoistから移行する準備が整ってしまいました。なお、一点課題があるのはGoogle Tasks APIは繰り返し予定の作成に対応していないので、 `!毎年12月24日 クリスマスイブ` みたいに入れても繰り返し予定にならないことです。
+
+## SaaS is Deadの示すもの
+
+数年前にSaaS is Deadという言葉が流行りましたが、AI（LLM）によって現実味が増しています。ちょっとしたものであれば、自作してしまう方が安価で、速く、自分の要件にフィットするものが作れるようになっています。
+
+この時、最も厳しいのが独自のデータベースがないものです。予定調整サービスがその最たるものです。データはGoogleカレンダーなどのカレンダーサービスに飛んでしまい、独自のデータがないのは致命的です。カスタマイズで様々な業務要件に対応したとしても、一人の顧客が使いたい要件は1つ、ないし2つしかなく、他の要件については過剰開発になってしまいます。
+
+独自のデータベースがある場合、それをベンダーロックインとして囲い込む戦略が取れます。ユーザーとしては喜ばしくないのですが、ベンダーロックインによって、使い続けてもらうことは可能でしょう。しかし、ユーザーからのオープンデータに関する要望があって、エクスポート機能をつけると、オープンソースの代替サービスにインポートされる可能性があります。Todoistの場合、タスクは終了させていくのが基本なので、1年前のデータにそれほどの価値がないのが辛いところです。
+
+オープンなプロトコル・基盤を代替するものは、スイッチングコストが低いのが利点でもあり、欠点でもあります。例えばパブリッククラウドのインスタンスであり、メール配信サービスなどです。SMTPでメール送信しているならば、その接続先を変更するだけで乗り換えができてしまいます。AWSで単にEC2インスタンスを立てているだけであれば、他のパブリッククラウドへも容易に乗り換えられるでしょう。
+
+オープンソースの代替サービスが続々登場するのも課題です。[OpenAlternative](https://openalternative.co/)では、さまざまなサービスのOSS代替を調べられます。もちろん、全機能が揃っていない場合が多いのですが、8割の要望が満たせるなら十分というケースは多いのではないでしょうか。
+
+## 生き残るSaaS
+
+では、生き残るSaaSは何があるでしょうか。一つは技術的複雑性を解決してくれるものです。代表的なものとしては、TwilioやStripeがあります。決済周りの仕組みは複雑で面倒なものですが、それをシンプルにしてくれます。もちろん、代替サービスはありますが、決済やSMS送信を行うSaaS市場はなくならないでしょう。
+
+次に法的な課題を解決してくれるものです。たとえばfreeeやSmartHRです。決算書を作成したり、請求書や見積書などを作成するというビジネス上必要なフローを代替してくれます。会計ソフトや労務ソフトは年々制度が変わるのに合わせてアップデートが必要です。ローカルソフトウェアにしたところでバージョンアップ費用は必要ですし、macOSなど複数のプラットフォーム対応を考えると、こうした市場はなくらないと想定されます。
+
+3つ目に、AI（LLM）に選ばれるSaaSです。最たるものとしてはSupabaseが挙げられます。何かデータベースが必要なWebアプリやスマートフォンアプリを開発する際に、Claude Codeなどを使うとSupabaseを要件に組み込んでくることが多いと感じられます。もちろん要件に合わない場合は外せば良いのですが、デフォルトで入ってくるとそのまま受け入れるケースも多いのではないでしょうか。LLMに聞いた時に、候補に上がってこないサービスは衰退していくと予想されます。
+
+4つ目は、継続性によって価値が生まれるものです。単純にデータを蓄積すれば良いというわけではなく、データのベンダーロックインでもありません。データが蓄積することで、新しいビジネス価値を提示できるものは、使い続ける価値があります。SalesforceやDatadogはその系統のサービスだと思っています。Datadogを入れて即価値を見出すのは難しいですが、データが蓄積されていくことで可視化される領域が広がっていき、サービス価値が感じられるのではないでしょうか。Salesforceも今現在の対応状況だけでなく、過去の履歴やクライアントの状況がグローバルに共有されるからこそ、価値があるでしょう。
+
+5つ目は、圧倒的な安価です。他社では真似できないレベルの安価であれば、選ばれる可能性があります。その最たる例がオープンソースです。オープンソース = 無料という認識はよくないですが、少なくともオープンソース・ソフトウェアであれば自社の責任において無償で利用できます。また、Cloudflareのように多くのサービスを無料で使えてしまうのも、他社との差別化になるでしょう。ただし、無料からの有料化は別な茨の道とも言えるので注意が必要です。
+
+最後はデファクトスタンダードです。最たるものがMicrosoft OfficeやAdobe、Autodeskです。デザイナーの中でのスタンダード、CADの世界でスタンダードになることで、どれだけ価格が上がっても使い続けざるをえない状態になっています。Affinityが無償化を実施しましたが、あれで環境を移せるのは個人ユーザーくらいでしょう。ビジネスで使っている場合、スイッチできない状態になっているのではないでしょうか。
+
+## まとめ
+
+もし自社サービスがSaaSの場合、この辺りの生き残り戦略を見極めておかないと、あっという間に乗り換えられてしまう可能性があります。スイッチ先はライバルの場合もあれば、オープンソースや自社開発の可能性もあります。
+
+AI、というよりLLMがSaaSの世界を一変しようとしています。2026年もまた、荒れそうで楽しみ（？）です。

package/_posts/en/2026-01-15-bye-bye-ai-text-writer.md

@@ -0,0 +1,42 @@
+---
+layout: post
+title: "I've Decided Not to Use AI for Writing Anymore expect translation"
+date: 2026-01-21 12:00:00 +0900
+lang: en
+---
+
+Since I started learning programming, I've been using Emacs, so it was natural for me to write and code in the same environment. From time to time, editors suitable for writing would appear, and I tried them, but they never felt quite right.
+
+Around 2018 (?), I switched from Emacs to VS Code, and I started writing blog posts and other content in VS Code as well. Then, around 2023, GitHub Copilot appeared. Press Enter, and it intelligently suggests code that looks just right. It autocompletes variable names and function names with ease—it was a revolutionary convenience.
+
+I think it was initially only effective for programming languages, but soon it started autocompleting documentation as well. It would generate suggestions in proper Japanese, seemingly understanding my intent. Wonderful!
+
+But that lasted only until recently. Regrettably, I've disabled GitHub Copilot for Markdown files.
+
+The reason is that I've increasingly felt that generative AI was pulling my thought process in its direction. I think everyone has their own way of writing, but in my case, I write more intuitively. As I gradually write, my thoughts become clearer and more articulate, eventually leading to a conclusion.
+
+With this style of writing, when a long suggestion appears and I accept it, my own thinking gets dragged in that direction. After accepting suggestions a few times, what I end up with is "something" completely different from what I originally wanted to write.
+
+Once I realized this, I understood that letting GitHub Copilot write for me wasn't working. If I don't create that initial spark myself, the result feels like a bland, lifeless piece of text.
+
+Of course, writing manually takes time, and there might be incoherent parts or typos. In such cases, it might be fine to let AI handle minimal editing.
+
+## Text Suitable for AI
+
+If there are documents that are suitable for AI creation, I think READMEs and documentation for software that's already been developed to some extent are good candidates. Since the underlying software code exists, having AI comprehensively examine it and create documentation seems like a good fit.
+
+Blogs, on the other hand, are different—they're a place for me to express concepts that exist within me. Having AI involved in that feels somewhat unsettling.
+
+## Translation Between English and Japanese
+
+Recently, there was a controversy on zenn.dev about an automatic English translation feature for blog posts.
+
+Having it enabled by default might not have been the best choice, but I think automatic translation itself is fine. There are many articles in Japanese with excellent content that don't reach a global audience simply because they're in Japanese.
+
+For example, when I want to share a Japanese article about CodeRabbit, it's a hassle to translate it into English before sharing it on Slack. I want to showcase the great engineers in Japan, but it's a real shame that the Japanese language becomes a barrier.
+
+Of course, there might be mistranslations, and someone might suddenly point them out, but isn't that all part of communication? If there are mistranslations, it's not my fault—it's an issue on zenn.dev's side. It's a waste to avoid global outreach because of fear of 0.001% mistranslations.
+
+## Conclusion
+
+So, this text was delivered with 0% AI flavor (only translation by Claude Code :-)).

package/_posts/en/2026-01-24-future-of-saas.md

@@ -0,0 +1,95 @@
+---
+layout: post
+title: "How Personal Development Revealed the Future of SaaS"
+date: 2026-01-24 12:00:00 +0900
+lang: en
+---
+
+I've been using Todoist for task management for a very long time. Looking back at my emails, it seems I started using it in October 2013. That means I've been using it for over 12 years. After failing at task management repeatedly, Todoist was the first tool that actually worked for me.
+
+With Todoist, I've been using the cheapest legacy business plan at 3,500 yen per year. Looking back, it was incredibly affordable, but this plan is being discontinued. The new business plan will cost 11,520 yen per year. There's also a Pro plan for personal use at 672 yen per month (8,064 yen annually). Whichever I choose, it's a 2-4x cost increase.
+
+With rising prices, price increases may be unavoidable in some cases. However, I feel that these kinds of SaaS price hikes are clearly driven by feature additions that users don't expect. Namely, AI. Todoist has also introduced an AI assistant called `Todoist Assist`. Frankly, it's unnecessary. If this price increase is a result of that, it's extremely disappointing.
+
+Adobe is another well-known example. Adobe's subscription has become more expensive year after year, and I feel this is largely due to the development burden of AI features. They say 80% of users don't use even 20% of features, and I think Photoshop and Illustrator are exactly like that. It's tough to pay for development costs of features unnecessary for most users.
+
+## Building Small Tools Yourself
+
+Since I'm already using Google Calendar (with Todoist integration), I decided to switch my task management to Google Calendar and Google Tasks.
+
+However, there's one problem. I need Todoist's incredibly convenient feature of "adding tasks via natural language." For example, being able to input tasks like "next Monday meeting #ProjectA [3 hours]" using natural language. macOS Calendar has a similar feature called Quick Event. However, iOS doesn't have the same functionality.
+
+Without this feature, entering tasks and scheduling calendar events becomes tedious, and it's clear it won't last long. I looked for OSS alternatives to Todoist, but none offered similar functionality.
+
+So I decided to build it myself.
+
+[goofmint/Text2Cal: Add schedule to your Google Calendar from natural language\.](https://github.com/goofmint/Text2Cal)
+
+Text2Cal is a very small tool. It runs on Google Apps Script in Google Sheets. It takes received text, sends it to ChatGPT, and converts it to JSON for schedule input.
+
+When you send a string like:
+
+`21th 18:00 Meetup event`
+
+It expands to JSON like this:
+
+```json
+{
+  "title": "Meetup event",
+  "start": "2026-01-21T18:00:00+09:00",
+  "end": "2026-01-21T19:00:00+09:00",
+  "location": null,
+  "label": "0",
+  "timezone": "Asia/Tokyo",
+  "recurrence": null
+}
+```
+
+This gets registered in Google Calendar. As a result, you get JSON back from Google Calendar like:
+
+```json
+{
+  "id": "l0g...udo",
+  "status": "confirmed",
+  "htmlLink": "https://www.google.com/calendar/event?eid=bDB...",
+  "colorId": "8"
+}
+```
+
+If you put `!` at the beginning of the input text, data is registered in Google Tasks. You input text like `!Today Issue Invoice`.
+
+Then you just create macOS/iOS shortcuts to send the input string to the Text2Cal web application. I use Google Sheets because it keeps logs of inputs and results, and makes it easy to use Google Calendar and Google Tasks APIs.
+
+With just this, I've created the functionality I personally need, and I'm ready to migrate from Todoist. One issue is that the Google Tasks API doesn't support creating recurring tasks, so even if you enter `!Christmas Eve every year`, it won't become a recurring task.
+
+## What "SaaS is Dead" Indicates
+
+The phrase "SaaS is Dead" became popular a few years ago, but AI (LLMs) has made it more realistic. For small things, building it yourself is cheaper, faster, and fits your requirements better.
+
+What's most challenging here are services without proprietary databases. Scheduling services are the prime example. Data goes to calendar services like Google Calendar, and not having proprietary data is fatal. Even if you customize for various business requirements, each customer only wants one or two requirements, making other requirements over-development.
+
+If you have a proprietary database, you can take a vendor lock-in strategy to retain users. While users aren't happy about it, vendor lock-in can keep them using the service. However, if there are user demands for open data and you add export functionality, it might be imported into open-source alternatives. With Todoist, since tasks are meant to be completed, year-old data doesn't have much value, which is painful.
+
+Services that replace open protocols and platforms have low switching costs, which is both an advantage and a disadvantage. Examples include public cloud instances and email delivery services. If you're sending email via SMTP, you can switch just by changing the connection destination. If you're just running EC2 instances on AWS, you can easily switch to other public clouds.
+
+The continuous emergence of open-source alternatives is also a challenge. [OpenAlternative](https://openalternative.co/) lets you find OSS alternatives to various services. Of course, they often don't have all features, but if they can meet 80% of needs, that's often sufficient.
+
+## SaaS That Will Survive
+
+So what SaaS will survive? One is those that solve technical complexity. Representative examples are Twilio and Stripe. Payment systems are complex and tedious, but they simplify them. Of course, there are alternatives, but the SaaS market for payments and SMS sending won't disappear.
+
+Next are those that solve legal issues. For example, freee and SmartHR. They replace necessary business flows like creating financial statements, invoices, and estimates. Accounting and HR software need updates as regulations change yearly. Even with local software, upgrade costs are necessary, and considering multi-platform support like macOS, this market shouldn't disappear.
+
+Third are SaaS chosen by AI (LLMs). The prime example is Supabase. When developing web apps or smartphone apps that need databases using Claude Code, I often find it incorporates Supabase into requirements. Of course, you can remove it if it doesn't fit, but when it's included by default, many cases probably accept it as is. Services that don't come up as candidates when asking LLMs will likely decline.
+
+Fourth are those where value emerges from continuity. This doesn't just mean accumulating data or vendor lock-in. Those that can present new business value as data accumulates are worth continuing to use. I think Salesforce and Datadog are this type of service. It's hard to see immediate value with Datadog, but as data accumulates, the visualization area expands and service value becomes apparent. Salesforce also has value not just for current response status, but because past history and client situations are globally shared.
+
+Fifth is overwhelming affordability. If it's so cheap that other companies can't imitate, it may be chosen. The prime example is open source. While "open source = free" is a misconception, at least open-source software can be used free of charge at your own responsibility. Also, Cloudflare offering many services for free differentiates it from others. However, note that monetizing from free is a thorny path.
+
+Finally, there's de facto standard. Prime examples are Microsoft Office, Adobe, and Autodesk. By becoming the standard among designers or in the CAD world, they create a situation where people must keep using them no matter how much prices rise. Affinity implemented free pricing, but probably only individual users can migrate. For business use, they're likely in a state where they can't switch.
+
+## Conclusion
+
+If your own service is SaaS, you need to identify these survival strategies, or you might be switched away quickly. The switch destination might be a rival, open source, or in-house development.
+
+AI, or rather LLMs, are about to transform the SaaS world. 2026 will likely be turbulent and exciting too.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "goofmint",
-  "version": "1.0.2",
+  "version": "1.0.4",
   "description": "個人ポートフォリオサイト",
   "homepage": "https://github.com/goofmint/goofmint.dev#readme",
   "bugs": {