Todoist CTO、AI は少ない方が成果が出ると語る不確実な状況
本文の状態
日本語全文を表示中
詳細モードで約8分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
The New Stack AI
Todoist を開発する Doist は、AI の予測不可能性を克服するため、生成には AI を使い実行には従来のコードを用いる「Automations」機能を公開し、コスト削減と信頼性向上を実現した。
AI深層分析を開く2026年8月7日 02:16
AI深層分析
キーポイント
生成と実行の分離による信頼性確保
Doist は AI の予測不可能性が自動化の実行段階で問題となるため、AI でワークフローを生成し、実際の処理は従来のコードで実行するアーキテクチャを採用した。
コストと速度の最適化
毎回大規模言語モデルを呼び出すのではなく CPU 上でコードを実行する方式により、自動化の実行コストを大幅に削減し、処理速度も向上させた。
ユーザー体験の簡素化
自然言語での指示だけで自動化が生成されるため、設定や温度調整などの複雑なパラメータをユーザーが意識する必要がないシンプルな設計となっている。
機能追加より削除を重視する哲学
Todoist は成熟した製品に未検証のアイデアが溢れるのを防ぐため、AI を活用しても「追加」よりも「削除」を優先する方針を採用している。
モデル変更とコスト管理のための評価プロセス
単一プロバイダーへの依存を防ぐため多言語・多シナリオでのテストを行い、高品質な結果を保ちつつ推論コストを最適化する戦略をとっている。
重要な引用
When you create an automation that you expect to run every time and to be consistent and predictable, you already have a problem because AI is not predictable and consistent by design.
So we had this idea. What if we leverage the AI's capabilities to generate a manifest, an automation that then we execute on some trigger-based or recurring basis?
A major advantage of keeping AI models out of the execution path whenever possible is that it is also far cheaper and faster to run code on a CPU than invoking an expensive model every time an automation runs.
"What we knew at the time was that we were not primed to build with AI," Silva says.
編集コメントを表示
編集コメント
生成と実行の分離というアプローチは、AI の実用化における重要な課題である「予測不可能性」への現実的な解決策を示している。この設計思想は、単なる機能追加ではなく、信頼性の高い自動化システムを構築するための新たな基準となる可能性がある。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。

Doist の CTO、ゴンサロ・シルバ氏は AI の行方について確信したように語ることはしない。変化のスピードが速すぎて、特定のロードマップやモデルプロバイダー、あるいは働き方に固執することが難しくなっているからだ。
「予測はできますが、10 個作っても互いに全く異なり、どれも正解である確率はほぼ同じです」とシルバ氏は The New Stack に語る。「つまり、これまで以上に不確定要素が多い領域で活動しているのです」
どの方向性が勝つかを予測しようとするのではなく、Doist(Todoist や Twist の開発元)は 1 年以上前に 3 つの広範な原則を定めた。第一に、AI 機能は目的を持つべきであること。第二に、プライバシーとセキュリティが守られるべきであること。第三に、モデルの変化に合わせて改善できる仕組みで構築されるべきであることだ。
Doist は、AI を使えばすぐに実装できても、それがリリースする価値があるとは限らないという教訓を得た。
初期の実験を通じて、Doist チームは「AI で簡単に作れるからといって、それをリリースする必要があるわけではない」ということも学んだ。
現在、Doist では Automations という新サービスがテストされている。これはユーザーにタスクを思い出させるだけでなく、実行まで支援する企業へと Doist を進化させるためのものだ。
Automations は、AI を活用してユーザーの自然言語によるリクエストを「マニフェスト(実行計画)」に変換します。その後、トリガーが作動したりスケジュールされたジョブが始まったりすると、大規模言語モデルではなく通常のコードがその手順を実行します。Doist の Silva 氏は、Automations は8月または9月初旬にクローズドベータから正式リリースされる予定だと述べています。
「毎回実行され、一貫性があり予測可能な自動化を作成する場合、すでに問題を抱えています」とSilva氏は指摘します。「なぜなら、AI は設計上、予測不可能で不確実なものだからです」
AI がワークフローを記述し、コードがそれを実行する
実際には、モデルはユーザーの意図を理解する点では優れていますが、同じ自動化が10回や100回と確実に実行されなければならない場面になると、問題が生じるとSilva氏は主張します。
「そこで生まれたアイデアです。AI の能力を活用してマニフェスト(自動化の手順書)を生成し、それをトリガーベースまたは定期的なスケジュールで実行するのはどうでしょうか」とSilva氏は語ります。「つまり、ユーザーが何を求めているのか、それが実行において何を意味するのか、実際に何をするべきかを判断する『生成フェーズ』ではAIを活用します。しかし、自動化そのものは予測可能である必要があります」
可能な限り実行パスから AI モデルを排除する最大の利点は、CPU でコードを実行する方が、自動化が実行されるたびに高価なモデルを呼び出すよりもはるかに安価で高速になる点にあります。その結果、モデルは毎回プロセスをゼロから再発明する必要がなくなります。
ユーザーは単に目的を記述するだけで、自動化が即座に実現される。シルバ氏は「それだけです」と語る。「設定モデルも不要、ツール呼び出しの制限もない、温度調整の設定もいらない。そんなものは一切ありません」
「追加よりも削除を」
この自動化システムは、シルバ氏が「追加よりも削除を」と呼ぶより広範な製品哲学の一部です。AI は機能の開発とリリースを容易にしますが、同時に完成された製品に、まだその地位を確立していないアイデアで埋め尽くすことも容易にしてしまいます。
Todoist は 7 月 13 日に「Goals」ベータ版の終了を発表し、この考え方を示しました。シルバ氏によれば、チームはこの機能に多大な投資を行いましたが、利用データと全体的な体験が基準を満たさなかったためです。
同社は、音声で脳内を吐き出すことを構造化されたタスクに変換する「Ramble」という新機能を立ち上げる際にも、似たようなアプローチを取りました。シルバ氏によると、Ramble の前に小規模チームはプロジェクトの要約など少なくとも 18 の AI アイデアのプロトタイプを作成しましたが、ほぼすべてを却下しました。シルバ氏が指摘する問題の一部は、当時同社がまだ本格的に AI を生産環境に導入する準備ができていなかったという点にあります。
「当時の私たちが知っていたのは、AI で構築するにはまだ準備が整っていなかったということです」とシルバ氏は語ります。「AI は新しい建築ブロックでした。これは約 1 年前、実際にはもう少し前の話です。その強力さは理解していましたが、実際のプロジェクトで使いこなす経験は十分ではありませんでした」
2007 年の創業以来、数百万人のユーザーに支えられてきた製品において、実験にはエンジニアリングの時間以外のコストも伴います。例えば「Goals」機能を削除した際にも、それが単なる実験だったにもかかわらず、コミュニティから一部反発を招きました。
シルバ氏はこう述べています。「ただ何でも付け足していけばいいわけではありません。そうすれば、すぐに誰にとっても使いにくいものになってしまいます。私たちは焦点を絞って取り組む必要があります。」
imageCredit: Todoist
モデルは変わっても、品質基準は保つべきだ
Doist は、裏側で同じ柔軟性を維持しようとしています。同社は AI 機能を特定のモデルプロバイダーに縛りつけたくないため、モデルを変更した際に挙動が変化しないかを確認するためにテストと評価を実施しています。シルバ氏によると、Ramble のテストスイートは約 18 か国語に対応し、それぞれについて数十のシナリオをカバーしているそうです。
これらの評価結果は、Doist が推論コストを管理する手段にもなります。チームはまず大規模で高価なモデルを使って機能を動作させ、その後、より小さく安価なモデルでテストを行い、同じ品質基準を満たすまで実装を調整します。これは、初期ベータ版の Automations 機能が数百人のユーザーだけで利用された際に巨額の請求書が突きつけられた際にも重要な役割を果たしましたとシルバ氏は語っています。
AI ツールへのアクセスをより多くの人々に開放しても、何かを生み出すことと、それが良いものかどうかを判断することの間の違いがなくなるわけではありません。Doist のシリバ氏は、当初はプロダクトマネージャー、デザイナー、エンジニアが互いの領域を自由に越えて活動できるという考えを受け入れていたと話しますが、これは期待通りに機能しませんでした。
「私たちはその波に乗りましたが、最終的に優れた仕事をするための基本的な原則を理解したと感じています。それは、専門知識と審美眼(センス)の両方が必要だということです」とシリバ氏は語ります。「このツールによって、多くの人が自律性や独立性を得られるのは素晴らしいことです。しかし、結局のところ、専門家こそが専門家であるという事実も認識する必要があります。
例えばプロダクトマネージャーを挙げると、長期的に保守可能で動作するコードを含むプルリクエストと、動作はするものの実装方法に疑問が残る別のプルリクエストの違いを見分けることはできません。しかしエンジニアなら見分けがつきます。」
これは Doist の全体的な AI 戦略全体に通じる共通のテーマのように感じられます。チームは、ワークフローの作成やアイデアの探求における障壁を下げるためにモデルを活用していますが、その新たなスピードが、最終的にユーザーに提供されるものの品質基準を下げることになってはいけません。
この投稿「Why Todoist says less AI can deliver more」は、The New Stack で最初に公開されました。
原文を表示

Doist CTO Gonçalo Silva doesn’t pretend to know where AI is headed. The pace of change has made it harder to commit to one roadmap, model provider, or way of working.
“I can make predictions, but I feel like I can make 10 of those and they are all very different from each other, and they almost all have a similar probability of being right,” Silva tells The New Stack. “So I’m operating in a space with more unknowns than ever.”
Rather than trying to predict which direction will win, Doist — the company behind products like Todoist and Twist — established three broad principles more than a year ago, Silva says: The first is that AI features should be purposeful; the second is that they should be private and secure, and the third is that they should be built to improve as models change.
Doist has learned that just because a feature is now easy to build with AI, that doesn’t mean it’s worth shipping.
Through its early experiments, the Doist team also learned that just because a feature is now easy to build doesn’t mean it’s worth shipping.
Doist is currently testing Automations, a new service that is meant to take Doist from a company that focuses on helping users remember tasks to one that helps them execute them as well.
Automations uses AI to turn a user’s natural-language request into a manifest. Then, when a trigger fires or a scheduled job begins, ordinary code — not a large language model — executes those steps. Doist plans to launch Automations out of its closed beta in August or early September, Silva says.
“When you create an automation that you expect to run every time and to be consistent and predictable, you already have a problem because AI is not predictable and consistent by design,” Silva says.
AI writes the workflow, but code runs it
As it turns out, models are great for interpreting what a user wants, Silva argues, but they become a problem once the same automation must run reliably for the 10th or 100th time.
“So we had this idea. What if we leverage the AI’s capabilities to generate a manifest, an automation that then we execute on some trigger-based or recurring basis?” Silva says. “So we do have AI in the generation phase where you need to figure out what the user is requesting and what that means in terms of execution, what should it actually do? But then the automation itself is predictable.”
A major advantage of keeping AI models out of the execution path whenever possible is that it is also far cheaper and faster to run code on a CPU than invoking an expensive model every time an automation runs. As a result, the model doesn’t have to reinvent the process every time it runs.
The idea here is that the user simply describes the intent and gets an automation back. “That’s it,” Silva says. “No configuration model, no tool call limits, no temperature settings, none of that.”
“Subtraction over addition”
The automation system is part of a broader product philosophy Silva calls “subtraction over addition.” AI makes it easier to build and ship features, but that also makes it easier to fill a mature product with ideas that haven’t earned their place.
Todoist offered a recent example when it retired its Goals beta on July 13. Silva says the team had invested heavily in the feature, but usage data and the overall experience didn’t meet its standards.
The company took a similar, but less dramatic path, to launch Ramble, Todoist’s voice-based feature for turning a spoken brain dump into structured tasks. Before Ramble, Silva says, a small team prototyped at least 18 AI ideas, including project summarization, and discarded all of them virtually. Part of the problem, Silva argues, was that the company simply wasn’t ready to bring AI into production yet.
“What we knew at the time was that we were not primed to build with AI,” Silva says. “AI was a new building block. This was about a year ago, a little more actually. And we knew this was very powerful, but we did not have enough experience using it in real projects.”
For a product that dates back to 2007 and serves millions of users, experiments also carry a cost beyond the engineering time. When the team removed Goals, for example, it prompted a bit of community backlash, even though the feature had only been an experiment.
“So if we just keep adding things, it’s not going to be very good for anybody very soon,” Silva says. “So we need to stay focused.”
imageCredit: Todoist
Models change, but the quality bar shouldn’t
Doist is trying to preserve the same flexibility under the hood. The company doesn’t want its AI features tied to a single model provider, so it uses tests and evaluations to check whether a model change alters their behavior. Ramble’s test suite spans about 18 languages and dozens of scenarios for each, Silva says.
Those evaluations also give Doist a way to control inference costs. The team can first make a feature work with a large, expensive model, and then test smaller (and cheaper) models and adjust the implementation until it meets the same quality bar. That became important when an early beta of Automations with only a few hundred users produced a massive initial bill, Silva says.
Giving more people access to AI tools hasn’t erased the difference between producing something and judging whether it is good. Doist initially embraced the idea that product managers, designers, and engineers could move freely into one another’s work, Silva says, but this didn’t work out as expected.
“We rode that wave, but I feel like we eventually really understood a basic principle of great work, which is you do need the expertise, and you do need the taste,” Silva says. “It’s great that we have this tool that enables so much autonomy and independence. But we also need to realize that at the end of the day, the expert is the expert.
A product manager — just picking a random example — will not be able to tell the difference between a pull request with code that works and is maintainable long term, versus another pull request that also works but is much more questionable in the way it’s built. An engineer will.”
It feels like this is the common thread across Doist’s overall AI strategy. The team uses models to lower the barrier to creating a workflow or exploring an idea, but that newfound speed shouldn’t lower the bar for what eventually ships to users.
The post Why Todoist says less AI can deliver more appeared first on The New Stack.
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み