毎朝5時半、僕のところには「朝礼」が届きます。
並列で動かしている5つのプロジェクト — ジャーナル、AIMusic、Japanese Lab、TOEIC自己実験、インフラ — の状態を、AIが前の晩から観察してまとめたブリーフィングです。そこには、こんな行が並びます。
ジャーナルは△、AIMusicは◎、インフラは「13/15 OK ⚠️」。
最初に違和感を持ってほしいのはここです。点数がついているものと、ついていないものがある。ジャーナルとAIMusicには◎や△という健全性スコアがついているのに、インフラやJapanese Labには数字や記号の生データしか並んでいない。
これは、作っているうちにそうなりました。今回は、その「健全性を記号で採点する自動監視」を設計・実装して2週間半動かした記録と、 そもそも健全性に点数をつけるとはどういうことだったのか という、作ってから気づいた話を書きます。
先に結論を出しておくと、 健全性を定義するという作業は、「自分の事業が何で死ぬか」を言語化する作業でした。そして、それが言語化できたプロジェクトだけが、今点数をつけられているもの、ということです。
なぜ「点数」にしたかったのか — 天井1の手前で詰まっていた
この監視を作った直接の動機は、前回の検証記事 — 「一人で、チームを超える」と書いた僕が見た、1人開発の天井 に書いた、天井1にあります。
天井1は「並列実行の物理上限」。サブエージェントをいくら並列で走らせても、戻ってきた出力を読んで、判断して、採否を決める作業は、僕一人の時間に乗ってくる、という構造の話でした。
この天井は、プロジェクトを並列で増やすほど、別の形で効いてきます。5つのプロジェクトそれぞれが「いま健全なのか」を把握する作業 が、丸ごと僕の頭に乗ってくるんですよね。
AIMusicの楽曲予約は何本残っているか。ジャーナルの次の公開分は予約済みか、音声は配置したか。daily_newsの自動収集は今日3回とも回ったか。Japanese Labのメンバーは増えたか減ったか。これを毎朝5プロジェクト、頭の中で確認する。並列で動かしているはずなのに、状態確認だけはシーケンシャルに僕を待っている。
最初に作ったAIの観察は、ただの生ログでした。「schtasks 13/15 OK」「楽曲予約6/16本」「join=1 leave=1」みたいな行が並ぶ。これはこれで正確なんですが、読むのに脳を使うんです。13/15は良いのか悪いのか。楽曲予約6本は足りているのか。毎朝、生データを解釈する認知コストが、そのまま天井1になっていた。
だから、一目で「今日はどこを触るべきか」がわかる信号が欲しかった。◎なら見なくていい、×なら今日中に手を打つ。健全性を、解釈済みの記号に圧縮したかった、ということなのです。
健全を定義する＝「何で死ぬか」を決める
ここからが、作ってから一番考えさせられた部分です。
「健全性に点数をつける」 って、簡単に言いますが、実際にコードに落とそうとすると、最初に決めなければいけないことがあります。何をもって◎とし、何をもって×とするか。この閾値を、自分で引かないといけない。
ジャーナルの健全性判定は、こう定義しました。
| 判定 | 条件 |
|---|---|
| × | 3日先までの水曜公開予定日に、予約と音声配置が完了していない日がある |
| △ | 7日先までの水曜公開予定日に、予約と音声配置が未完の日がある |
| ○ | 7日先まで完了。ただし7日より先のアイデア在庫が5本未満 |
| ◎ | 7日先まで完了。かつ7日より先のアイデア在庫が5本以上 |
AIMusicは、楽曲ベースで定義しました。
| 判定 | 条件 |
|---|---|
| × | 楽曲予約が0本、かつ公開待ちの完成曲も0本（公開できる弾も予約もない） |
| △ | 楽曲予約が1本以下、または完成曲0本かつ直近3日コミットなし（在庫切れ間近） |
| ○ | 楽曲予約が2本以上（次回分の公開予定は積んである） |
| ◎ | 楽曲予約が4本以上（数曲先まで予約済み） |
この2つの表を作ったとき、気づいたんです。これは健全性の定義じゃなくて、失敗モードの定義だ と。
ジャーナルの×は、「公開が止まる寸前」 を意味します。AIMusicの×は、「出す弾が尽きた」 を意味する。どちらも、 そのプロジェクトが何で死ぬか を先に決めて、そこからの距離を4つの記号に割り当てているだけ なんですよね。
ジャーナルもAIMusicも、共通の失敗モードを持っています。 在庫が切れると、公開が止まる。コンテンツのパイプラインって、結局これに尽きる。だから「公開予定がどれだけ先まで埋まっているか」という一本の軸で、健全性を4段階に圧縮できた。
健全とは何か、を決めるのは、抽象的な品質論だと思っていました。これは、自分の事業が何で死ぬのかを、正直に1行で書けるか という話だった。これは、フィロソフィーの行動原則、「正直に検証する」 の、地味だけど一番具体的な実装だった気がします。
どう作ったか — 観察する5体と、まとめる1体
仕組みの骨格だけ、簡単に書いておきます。
構成はシンプルで、 5体の観察役（ingestor）と、1体のまとめ役（Director） です。
観察役は、プロジェクトごとに1体ずつ。ジャーナルならWordPressの予約投稿状況と音声ファイルの有無とアイデア在庫を、AIMusicなら楽曲制作パイプラインの予約数とコミット履歴を、それぞれ純粋なPythonで読みに行って、観察結果を1つのMarkdownファイルに書き出す。これがWindowsのタスクスケジューラで、毎日決まった時刻に自動で走ります。
まとめ役のDirectorは、5体の観察結果を全部読んで、朝礼ブリーフィングを生成する。ここだけはAIに任せていて、 claude -p というコマンドライン経由でClaudeを呼んでいます。判断材料を構造化するのが目的なので、特別なAPI契約は使わず、普段の Claude Max プランの枠内で完結させています。
作る中で踏んだ設計上の罠を、2つだけ書いておきます。どちらも 「静かに壊れる」 系で、後の自問パートに直結します。
1つ目は、 観察する時刻によって意味が違う という問題。インフラの状態は「前の晩の最終状態」を見たいけれど、ジャーナルの公開状況は「当日の朝の最新」を見たい。なので、観察系（インフラなど）は前日の夜だけ、制作系（ジャーナル・AIMusic）は前日の夜と当日の朝の両方を観察させて、まとめ役が朝礼を組むときに「制作系は当日の朝のぶん、観察系は前日の夜のぶん」を優先して読むようにしました。観察役そのものを朝夜で振り分けたというより、 制作系にだけ朝の観察を足して、読む側で時刻を使い分けている 、という二段構えです。
2つ目は、 古い観察が新しい観察を上書きしてしまう 問題。最初の実装では「その日の観察ファイルが既にあれば、書かない」という素朴なルールにしていたら、テストで作った古いデータが、本番の新しいデータの上書きを拒否する、という事故が起きました。これはタイムスタンプを比較して「新しい方が勝つ」方式に直しています。
このあたりは、SREの世界でいう「ヘルスチェック」とほぼ同じことを、個人の事業規模で素人なりにやっている感覚です。プロのインフラ監視には遠く及ばないけれど、 自分の事業の死活を、自動で観察して、解釈済みの記号で受け取る という構造だけは作れました。
2週間半動かして出たデータ
観察を動かし始めたのが5月11日。そこから5月28日までの2週間半に出た観察ログを抜粋します。
| 日付 | プロジェクト | 観察内容 |
|---|---|---|
| 5/11 夜 | journal | publish=1 (codex-plus-trial-start) / 音声1本 / 次予約05-13 / アイデア9本 / ◎ |
| 5/13 朝 | journal | publish=1 (ai-reading-paradox) / 次予約05-13 / ⚠️drift=05/20(予約なし) / △ |
| 5/15 朝 | journal | publish=1 (solo-dev-ceiling) / 音声0 / △ (05/22予約なし) |
| 5/17 夜 | journal | publish=1 (weekly_w20) / 音声1本 / 次予約05-18 / ◎ |
| 5/20 朝 | journal | 次予約05-20 / △ — 05/27(予約なし/音声なし) |
| 5/22 朝 | journal | publish=1 (ai-pace-gap, 50本目) / 次予約05-22 / ◎ |
| 5/25 朝 | journal | publish=1 (milestone-retrospective) / 次予約05-25 / ◎ |
| 5/27 朝 | journal | publish=1 (independence-report-card) / 次予約05-27 / △ — 06/03(予約なし/音声なし) |
| 5/28 夜 | journal | future=0本 / △ — 06/03(予約なし/音声なし) |
| 5/14 朝 | ai_music | commit 24h=2 / 7d=4 / 楽曲予約6/16本 / ◎ |
| 5/18 朝 | ai_music | commit 24h=3 / 7d=8 / 楽曲予約5/13本 / ◎ |
| 5/22 朝 | ai_music | commit 24h=2 / 7d=9 / P5公開待ち=2本 / 楽曲予約5/全13本 / ◎ |
| 5/25 夜 | ai_music | commit 24h=0 / 72h=0 / P5公開待ち=0本 / △ — 在庫切れ間近 |
| 5/28 朝 | ai_music | commit 24h=6 / 7d=17 / P5公開待ち=4本 / 楽曲予約9/全24本 / ◎ |
| 5/28 夜 | ai_music | commit 24h=15 / 7d=28 / P5公開待ち=2本 / 楽曲予約13/全32本 / ◎ |
ジャーナルの△が、しっかりと仕事をしていました。
5月20日の朝、ジャーナルの判定が△に落ちて、理由に「05/27 予約なし/音声なし」と出ています。これは、5月27日の公開予定記事の予約と音声が、まだ準備できていないことを、システムが先回りで検知した、ということです。僕が 「そろそろ次の記事を準備しないと」 と頭の中で思い出す前に、△という記号が朝礼に並んでいた。
その後は準備をおこない、5月27日の記事 は予定通り公開できました。△の検知から、ちょうど1週間の余裕がありました。
これが、点数化したかった理由そのものです。「05/27、予約なし、音声なし」という生データを毎朝解釈する代わりに、△という記号を一目見て、今日やることが決まる。 解釈の認知コストを、システム側に寄せられた。
そして、その5月27日の朝。ジャーナルは独立7ヶ月の記事を予定通り公開した、その同じ日に、また△に落ちています。理由は「06/03 予約なし/音声なし」 — 次の水曜の記事の準備が、また始まっていない とシステムが先回りで検知したわけです。1本片付けたら、次の1本に向けて、即座にカウントが始まる。1週間の余裕は、毎週リセットされて毎週やってくる、という当たり前のことを、システムは毎日落ち着いて並べてきます。
AIMusicの方は、最初の数日まだ判定がついていませんでした。観察役は動いていたけれど、◎/×を出すルールを後から足したので、健全性スコアが並び始めたのは5月13日から。そこから5月25日まで、AIMusicはずっと◎でした。楽曲予約が常に4本以上あったから。これは健全という意味でもあるし、 ◎が続くと人は見なくなる という別の問題の入り口でもあります。
その「見なくなる」が、5月25日の夜に終わりました。AIMusicが初めて△に落ちて、理由は 「在庫切れ間近: P5公開待ち=0本、直近3日のコミット=0本」。楽曲制作パイプラインの仕掛り在庫が枯れて、コミットも止まっていた、ということです。Suno側の作業が連休的に止まっていた区間で、その停止を「○の中の沈黙」ではなく「△の点灯」として並べてくれた。気づいて、25日夜から手を動かして、3日後の5月28日の朝には◎に戻っています。直近24時間のコミットは6本、P5公開待ちは4本に積み戻し済み。同日夜にはさらに、24時間コミット15本、楽曲予約13本まで増えていました。AIMusicも、△が一度ちゃんと仕事をした。これで採点できる2本のどちらも、検知された側として実例を持ったことになります。
自問1 — 点数をつけられたのは、5本中2本だけだった
ここで、冒頭の違和感に戻ります。
5つのプロジェクトを監視しているのに、記号による健全性スコアがついているのは、ジャーナルとAIMusicの2本だけ。残りの3本 — インフラ、Japanese Lab、TOEIC自己実験には、点数がついていません。
最初は「まだ実装していないだけ」だと思っていました。でも、3本それぞれに点数をつけようとして、手が止まったんです。つけられなかった。
理由は、さっきの「健全＝何で死ぬか」に戻ります。
ジャーナルとAIMusicは、失敗モードが1本に絞れた。「在庫が切れると公開が止まる」。だから在庫の距離を4段階にできた。でも、残りの3本は、そう簡単じゃなかった。
インフラの健全性は、多次元です。タスクが14個中いくつ成功したか、ディスク残量、daily_newsが3回とも回ったか、エラーの痕跡が残っていないか。これらを無理やり1つの◎/×に潰すと、「13/15 OK」の2個の失敗が、致命的なのか無視していいのかが消えてしまう。実際、ある晩は「11/14 OK」で、その中身は4日連続で同じ2つのタスクが固着していた。これを◎や△の1記号に圧縮していたら、 どのタスクが、何日、落ち続けているか という一番大事な情報が消えていた。だからインフラは、あえて生のNGタスク名を残す形にしています。
Japanese Labは、そもそも「健全/不健全」で測るものじゃなかった。メンバーが増えた減ったは、良し悪しではなく、ただの事実です。コミュニティの状態を◎/×で採点するのは、傲慢でもある。
TOEIC自己実験は、進捗であって健全性ではない。Day 21（5月28日時点）、フェーズ0のCalibration、というのは、遅れているとも進んでいるとも一概に言えない。
整理すると、こうです。
| プロジェクト | 失敗モード | 採点 |
|---|---|---|
| ジャーナル | 在庫切れ → 公開停止（一次元） | ◎/○/△/× で可能 |
| AIMusic | 楽曲在庫切れ → 公開停止（一次元） | ◎/○/△/× で可能 |
| インフラ | タスク失敗・容量・収集欠落（多次元） | 生データのまま残す |
| Japanese Lab | 「死ぬ」概念がそぐわない | 事実を観察するだけ |
| TOEIC | 進捗であって健全性ではない | フェーズと日数を出すだけ |
健全性に点数をつけられる対象は、失敗モードが単純に1本化できる対象だけ。これが、作ってからわかった一番大きいことでした。全部を一律に◎/×で採点しようとしていた最初の設計は、間違っていた。採点できないものを無理に採点すると、情報が落ちる。
天井1の対策として作った監視が、結局 「観察視点の単数性」=天井2 に触れている、とも言えます。何を健全とみなすか、という軸を引いているのは、僕一人の主観です。失敗モードを1本化できると判断したのも僕。AI由来でない誰かが見たら、ジャーナルの健全性をもっと別の軸で測るかもしれない。
自問2 — 監視は、ルールベースの固定閾値にすぎない
もう一つ、正直に書いておきます。
「AIに採点させる」と書きましたが、記号を決めているのは、AIの判断ではありません。 「楽曲予約が4本以上なら◎」みたいな、固定の閾値ルール です。Pythonのif文で書いた、ただの数値比較。
AIがやっているのは、観察結果を読んで朝礼の文章にまとめる部分だけで、健全性の判定そのものは、僕が手で引いた閾値が機械的に出している。だから「AIに事業を採点させる」というタイトルは、半分は誇張です。実態は「僕が決めた基準を、システムが毎朝代わりに当てはめている」。
これは弱点でもあり、たぶん正しさでもあります。健全性の基準みたいな、事業の生死に直結する判断を、AIの裁量に丸投げするのは怖い。閾値は僕が引いて、当てはめだけ自動化する。この線引きは、いまのところ意図的に守っています。
自問3 — 監視そのものが、静かに壊れた
一番不格好な話を最後に書きます。
「静かに壊れる」というのは、僕がこの手のシステムで一番警戒している失敗モードです。エラーで止まってくれれば気づける。怖いのは、 動いているように見えて、間違った答えを出し続ける 壊れ方です。
監視を作ったら、その監視自身が、何度も静かに壊れました。2週間半で起きたものを並べます。
| 事故 | 何が起きたか | どう直したか |
|---|---|---|
| daily_newsの誤報（2回） | テスト中に作った「1回しか回っていない」古い観察データが、本番の「3回とも回った」新しいデータの上書きを拒否し、翌朝の朝礼に「障害発生」と誤報を出した | タイムスタンプを比較して「新しい方が勝つ」方式に変更 |
| 観察ファイルの孤児化 | 5体の観察役が同時に起動して保存時に競合し、1体の観察結果がどこにも記録されないまま宙に浮いた | 手作業で取り込み直し。同時起動の競合自体は残課題 |
| 朝礼が丸ごと消えた | まとめ役のブリーフィング生成が112.3秒かかり、120秒のタイムアウトに引っかかって落ちた。観察データが7日分×5プロジェクトで満杯になり生成時間が上限に張り付いていた。落ちてもエラーログが残らない設定で、原因究明に時間がかかった | タイムアウト上限を上げ、ログを残すよう改修 |
| NGタスク名が見えない | インフラが「11/14 OK」とだけ記録し、どの3つが失敗したのか追跡できなかった | NGタスク名を観察に残す改修を追加 |
並べると情けないんですが、これが正直な実態です。自分の事業の死活を監視する仕組みを作ったら、その監視自身に死活監視が必要だった。
ここで効いてくるのが、 「気づける範囲では事故がない」は「気づけない範囲も事故がない」を意味しない という、自分への戒めです。監視を作ると、安心して見なくなる。◎が並んでいると、その◎が正しいかを疑わなくなる。でも、上の4件は全部、◎や正常表示の裏で起きていた。 監視は、新しい盲点を作る装置でもある。
ただ、これを欠点の話だけで終わらせるのは、たぶん正確じゃない。 壊れたこと自体は擁護しません。でも、壊れ方が見える形で壊れて、その場で直していけること自体は、むしろ健全だと思っています。誤報は2回目で根治した。タイムアウトは上限を上げてログを残すようにした。NGタスク名も後から見えるようにした。どれも、走らせていなければ表に出てこなかった改良です。
KaleidoFuture を 「Build in Public — 作る過程ごと公開する姿勢」でやっている以上、 完成品を出すことより、不完全なものを動かしながら直していく過程そのものを見せることの方が、本筋 だと思っています。監視が新しい盲点を作る装置だとしても、その盲点は、動かして初めて輪郭が出る。止めていたら、4件の事故は「起きなかった」のではなく、 「見えないまま潜在していた」だけ です。
これは、 「AIエージェントチームを組む」の意味が、組織とソロで全然違った で書いた、ソロでAIエージェントを束ねる難しさの、具体的な続きでもあります。
監視を作った後で、運用する仕組みも作ることになった
監視が2週間半動いて、◎がついた2本と、生データを残した3本と、4回の事故、というところまで来たところで、この監視基盤を次にどうするか を考える必要が出てきました。
採点できなかった3本（インフラ・Lab・TOEIC）を、無理に採点する側に寄せるのか。それとも、採点できるものとできないものは分けたまま運用するのか。5月24日、その採点方針を含めて、AIに反論役・別視点役・先読み役の3席を回してもらいながら整理する時間を取りました。結論は後者でした。
同じ日、もう一つ動いていた話があります。daily_newsの古い収集系（v1/v2）を退役させて、新しい系統だけに統一する作業を、その朝に実施しています。実は、朝礼の「daily_news 0/3」誤報を出していた直接の原因は、退役予定の古い系統に起因する観測の構造的欠落でした。「採点できなかったものを別扱いにする」と、「うまく測れない原因そのものを退役させる」が、同じ土曜の判断として並んだ ことになります。
そして、3席の議論をしているうちに、もう一つ気づきました。 監視は作ったけれど、毎朝届く朝礼を僕がどう受けて、何を返すか、という運用の動線が手作業のままだった。朝礼が届く、それを読んで議論する、結論が出ても誰もboardに書き戻していない、という非対称性です。
なので、その土曜のうちに、朝礼を受ける側と、判断を返す側を、それぞれ小さな仕組みに切り出しました。翌朝、その2つで初めて一周回したのが、まさに「測れない構造の根治を、別タスクとして切り出す」という判断でした。土曜朝のカットオーバーで daily_news の退役自体は終わっているけれど、 土曜の週次アーカイブが観察側を構造的に欺くという別軸のバグは未解決のまま残っている。これを期限つきの独立タスクとして起票して、日曜のループは終了しました。
並べてみると、こうなります。
| いつ | 何を分けたか |
|---|---|
| 土曜の朝 | 新しい収集系 ↔ 退役する古い系統（測定対象） |
| 同じ土曜 | 採点できる対象 ↔ 採点できない対象（運用方針） |
| 同じ土曜 | 朝礼を受ける動線 ↔ 判断を返す動線（運用ループ） |
| 翌朝（日曜） | 完了した判断 ↔ 残った構造バグ（議題） |
監視を作ったら、その監視を運用する側にも仕組みが要った。さらにその運用ループを一周回したら、新しい「分ける」が出てきた。 前回の検証記事 で書いた天井1（並列実行の判断スループット）は、「読む」だけでなく「決めたあと書き戻す」工程も含めて天井1なんだ、というのが、この週末でわかったことでした。
実装ノート — 健全の定義は、事業の定義だった
長くなったので、まとめます。
この監視を作る前、僕は「健全性に点数をつける」を、技術的なタスクだと思っていました。観察して、閾値で判定して、記号を出す。それだけだと。
実際にやってみてわかったのは、 健全を定義する作業は、事業を定義する作業だった ということです。何をもって◎とするかを決めるには、そのプロジェクトが何で死ぬかを、先に正直に書かないといけない。それが書けた2本だけが採点できて、書けなかった3本は、生データのまま残った。これは失敗ではなく、 採点できる対象とできない対象の輪郭が見えた という収穫だったと思っています。
そして、監視は注意を節約する装置であって、判断を代行する装置ではない。◎は「見なくていい」ではなく「今日は他に時間を使っていい」という意味で、×が出たら判断するのは結局僕です。スコアが片付けてくれるのは認知コストだけで、責任は片付かない。
少なくとも、 全部を一律に◎/×で測ろうとするのは、やめようと思っています。測れないものを測ろうとすると、情報が落ちる。これだけは、2週間半動かして体で覚えました。
今回のジャーナルから見える次の動詞は、「分ける」だと思っています。
FAQ
この監視って、市販の監視ツール（DatadogやMackerel）じゃダメだったの？
サーバーやアプリの死活監視なら市販ツールの方が圧倒的に優秀です。でも今回測りたかったのは「ジャーナルの次の公開が準備できているか」「楽曲の在庫が尽きていないか」みたいな、事業固有の健全性でした。これは汎用の監視ツールの守備範囲外です。インフラ部分（タスクが回ったか、ディスク残量）は市販ツールでも測れますが、そこはあえて生データのまま残しているので、結局「事業の失敗モードを自分で定義する」部分は自作するしかなかった、というのが実感です。
◎/○/△/×の閾値（楽曲予約4本で◎など）は、どう決めたの？
正直に言うと、最初は感覚です。「数曲先まで予約があれば安心して他のことができる」という体感を、楽曲4本という数字に置いた。ジャーナルの「7日先まで予約と音声が完了」も同じで、週1公開なので1〜2本先まで埋まっていれば慌てない、という肌感覚を条件にしています。本文に書いた通り、この閾値はAIではなく僕が手で引いたルールです。運用しながら、◎が出っぱなしなら閾値が甘い、×が頻発するなら厳しすぎる、と調整していく前提の暫定値です。
点数をつけられなかった3本（インフラ・Lab・TOEIC）は、今後つけるの？
つけられるものは、つけるかもしれません。たとえばインフラは「致命的なタスクが1つでも落ちたら×」のように、失敗モードを1本に絞れれば採点できます。でも、Japanese Labのメンバー増減を◎/×で採点するのは、たぶんずっとやりません。コミュニティの状態を健全/不健全で裁くのは、測る対象を間違えていると思うからです。本文の結論通り、「採点できるものとできないものを分ける」が次の方針です。
監視が4回も誤報・故障したのに、作った意味はあったの？
ありました。理由は2つで、1つは誤報が全部「見える形」で起きて、構造的に直せたこと。静かに間違い続けるより、派手に壊れて記録に残る方が、長期的にはずっと健全です。もう1つは、ジャーナルの△が5月27日の準備不足を1週間前に検知して、結果として予定通り公開できたような、ちゃんと仕事をした場面もあったこと。完璧な監視を作るより、不完全な監視を動かしながら直す方が、僕の性に合っています。「全部完璧にしてから動かす」は、僕の場合いつまでも動かさない言い訳になるので。
「AIに採点させる」と言いつつ、判定はルールベースなら、AIは何をしているの？
AIがやっているのは、5つの観察結果を読んで、人間が読みやすい朝礼の文章にまとめる部分です。「ジャーナルが△で、理由はこれで、今日はこれをやるといい」と日本語で構造化するところ。健全性の判定（◎か×か）そのものは、僕が決めた閾値ルールが機械的に出しています。事業の生死に関わる判断基準をAIの裁量に丸投げするのは、いまは意図的に避けています。閾値は人間が引いて、当てはめと要約を自動化する、という線引きです。
この記事が参考になったら
Share