AIが書く仕事の日本語から、
特有の手癖と薄さを根絶する。
natural-japanese は、Claude Code や Cursor、ChatGPT で動く Agent Skill です。AI が書く日本語特有の「手癖」と「薄さ」を取り除き、読みやすく簡潔な仕事の文書に仕上げます。
AIに「もっと自然にして」と頼んでも、自分自身の学習手癖を客観的に認識できないため、別の紋切り型フレーズに置き換わるだけになりがちです。書き上がった文章からAI臭を抜くのは、料理のあとから塩を抜くような難しさがあります。
だからこそ、「書く前・書いた直後・推敲ループ」の3重防御で防ぎます。
12箇条の「文体憲法」と見出し骨格で縛り、最初から歪みやダラダラ説明の発生を防ぐ。
sudachipy（形態素解析）による lint.py が、禁止フレーズや翻訳調を決定論的に検出。
静的検査を通過した文章を「6軸ルーブリック」で自己採点し、密度と体温を注入して改稿収束。
文章はどう変わるのか（Before / After）
禁止語がない「静的チェック合格」の文章が、推敲ハーネスでどう引き締まるか。
近年、働き方改革やリモートワークの重要性がますます高まっています。組織におけるコミュニケーションの円滑化は、チームの成果を左右する極めて本質的な課題であると言えます。本節では、非同期コミュニケーションを定着させるための具体的な手法について詳しく見ていくことにしましょう。
「メンションされたら10分以内に返信する」という暗黙のルールを廃止した。これだけで、開発者がコードに没頭できる時間は1日あたり2.4時間増えた。非同期コミュニケーションの肝は、即レス文化を組織として意識的に諦めることだ。
本ツールは、仕事の日本語を読みやすく書くための Agent Skill です。書く前の設計、書くときの制約、書いた後の検査の全工程に組み込まれます。禁止語の除去だけでなく、読解負荷の改善までを総合的に支援します。
見出しは中身を言わず、どの段落も同じような長さで均等に並び、当たり障りのない結論で安全にまとめられる。あとから手作業で直そうとしても、骨組み全体に手癖が染み込んでいて、結局ゼロから書き直したほうが早いと感じることも少なくありません。
アプローチの柱は2つあります。第一に、あとから直すより書く前に防ぐこと。第二に、検出は機械が行い判断は人間が行うことです。修正が新しい指摘を生まなくなるまで——つまり収束するまで——ループします。
書き上がった文章からAI臭を抜くのは、料理のあとから塩を抜くような難しさがあります。そのため書く前に見出し骨格を固め、文体憲法で最初から歪みを抑えます。混ざった手癖は機械で突きつけ、文脈に合った修正だけをエージェントが判断します。
実機検証 ①
【ビジネス・業務改善】定例会議（18人）を廃止しSlack非同期共有へ移行する提案
開く
月曜午前の週次全体定例会議の見直しについて
✕ 「見直しについて」と何をするのか結論を言わない抽象タイトル。
月曜午前の全体定例（18人）を廃止し、Slack非同期報告へ移行する提案
✓ 人数・廃止・Slack非同期移行という核心がタイトルだけで伝わる。
1. 提案の概要 / 2. 背景 / 3. 現状の課題
毎週月曜午前に開催している全体定例会議を廃止し、Slackを使った非同期報告へ移行することを提案します。定例会議の目的である「各チームの状況共有」と「全社的な課題の把握」は維持します。一方、情報を一斉に読み上げるための会議はなくし、議論や意思決定が必要な案件に限って、関係者で個別に打ち合わせを設定します。
主な課題は次のとおりです。
- 報告の読み上げが中心で、会議でなければ成立しない内容が少ない
- 自分の業務と関係の薄い報告にも、全員が同じ時間を使っている
- 月曜午前の集中時間が分断され、業務の立ち上がりが遅れる
参加18人のうち発言者は3人。月72時間の拘束が形骸化しています
毎週月曜10時からの全体定例会議には、現在18名が参加しています。
直近1ヶ月の録画を見返したところ、実質的に発言していたのは各事業部長と司会の3〜4名だけでした。残る14名は、画面の向こうで別の作業をしながら自チームの番を待つ状態が常態化しています。正直、大きな無駄が生じていると感じています。
1時間の会議に18名が参加すると、会社全体で毎週18時間、月間72時間もの工数が拘束されます。人件費換算では月間約30万円、年間360万円にのぼる計算です。
何より問題なのは、一週間のスタートダッシュを切るべき月曜の集中作業時間が、受動的な聞き役に回ることで削がれてしまっている点です。
4. 移行によって期待できる効果
時間を有効に使える: 各自が必要な報告だけを確認できるようになります。全員が同じ時間帯に集まる必要もなくなり、月曜午前を計画作成や集中作業に充てられます。
情報が記録として残る: Slackへの投稿であれば、内容を検索・参照できます。欠席や休暇という概念もなくなり、時差勤務やリモート勤務のメンバーも同じ情報にアクセスできます。
報告の質をそろえやすい: 投稿形式を統一することで、進捗、今週の予定、課題、支援依頼を簡潔に把握できます。
月曜正午までの「Slack定型スレッド報告」に一本化します
全員を一箇所に集めてスライドを読み上げる運用をやめ、Slackの専用チャンネル（`#all-weekly-updates`）への非同期報告に切り替えたいと考えています。
各チームのリードは、月曜正午までに以下の3点だけをスレッドに投稿します。
- 先週の成果と数字（定量的実績）
- 今週やること（優先度トップ2）
- 他チームへの相談・ブロッカー（あればメンション付き）
各自は昼休憩や午後の始動時にこれを流し読み、疑問や相談があればスレッド上でやり取りします。全体の状況把握にかかる時間は各自10分程度に縮まります。
5. 懸念点と対策
投稿が読まれなくなる: 未読のまま情報が流れる可能性があります。専用チャンネルを設け、投稿日時と書式を統一します。
チーム間の接点が減る: 交流や横断的な相談については、別の機会を意図的に用意します。
緊急の課題への対応が遅れる: Slack投稿だけで完結させず、緊急案件については担当者への直接連絡や短時間の打ち合わせを併用します。
議論が必要な案件だけを「3人・15分」で即座に設定します
「会議をなくすとチーム間の接点が減るのではないか」「緊急の課題が見落とされるのではないか」という懸念はもっともです。
ただ、18名が集まる場で突っ込んだ議論や意思決定を行うのは困難です。情報共有のための「報告」と、意思決定のための「議論」を明確に切り分けます。
全社的な相談や急ぎのトラブルは、Slackの報告を見てから関係者3〜4名だけを招集し、15分のスポット打ち合わせで即決します。大人数で時間を浪費するより、必要なメンバーだけで素早く動くほうがスピードも上がります。
6. 今後の進め方 / 7. 議論したい事項
まずは4週間、試行期間を設けることを提案します。週次報告専用のSlackチャンネルを用意し、各チームが月曜正午までに報告を投稿します。試行終了時に、削減できた時間や情報共有の不足を確認し、正式移行を判断します。
会議を廃止すること自体が目的ではありません。情報共有の質を保ちながら、全社で使う時間を減らし、必要な議論に集中できる運用へ切り替えることが本提案の狙いです。
来週から3週間のパイロット運用をご提案します
いきなり全面廃止するのではなく、まずは来週から3週間、定例会議を休止してSlack運用を試験したいと考えています。3週間後の金曜日に全社アンケートを実施し、以下の基準で本移行を判断します。
- 情報共有の満足度: 各自が「他チームの状況を把握できた」と回答する割合が80%以上
- 時間の有効活用: 80%以上のメンバーが「月曜午前の業務効率が上がった」と実感していること
大きな支障が生じた場合は、即座に従来の会議体へ戻します。まずは来週月曜からの試行をご承認いただけますでしょうか。
実機検証 ②
【技術・インフラ刷新】セッション管理をRedisからCloudflare KVへ移行する提案
開く
セッションストレージのRedisからCloudflare KVへの移行検討
✕ 「移行検討」と当たり障りのない安全なタイトル。
Redisのセッション管理をCloudflare KVへ段階移行する提案
✓ 「段階移行」とアプローチを明快に宣言。
1. 背景 / 2. 現状の課題
現在、ユーザーのログイン状態や一時的なセッション情報をRedisで管理している。Redisは高速で整合性にも優れる一方、インフラの運用、障害対応、容量設計、リージョン間通信などに継続的な負担がかかっている。
主な課題は次のとおりである。
- Redisクラスタの監視、バックアップ、バージョン更新、障害対応が必要になる
- エッジ環境からRedisへ接続する際、ネットワーク遅延が発生する
- 接続数やコネクションプールを考慮した設計が必要になる
先月の障害で見えた、中央集権Redisの限界
先月14日、東京リージョンのネットワーク瞬断が起きた。このとき、セッション確認のリクエストがRedisの前段に一斉に滞留し、結果としてサービス全体の全API応答が20分以上にわたって深刻に遅延した。
痛かった。復旧対応のあいだ、障害通知のアラートが鳴り止まなかった。
現在、月間8,000万件にのぼるAPIリクエストをCloudflare Workersで受けている。だが、セッション参照のためだけに東京のRedisクラスタへ都度問い合わせているのが現状だ。エッジでいくら素早くリクエストを拾っても、東京との往復で30〜50msのレイテンシが必ず挟まる。遅い。
加えて、3ノード構成のRedisクラスタに月額約22万円を支払っている。運用負担も重い。実態を調べたところ、書き込みは全体の4%未満だった。残る96%は、単純なユーザーIDと有効期限の照合にすぎない。中央集権的なインメモリDBを抱え続けるコストが、提供価値に見合わなくなってきた。限界だ。
3. Cloudflare KVへ移行する理由
Cloudflare KVは、世界各地から読み出されるデータを扱うことに適した分散型のキーバリューストアである。セッション情報をKVに配置することで、次の効果が期待できる。
- 利用者に近い拠点からセッションを参照できる
- Redisへの外部接続や接続管理を減らせる
- サーバーやクラスタの保守作業をCloudflare側へ委ねられる
- アクセス量の増減に合わせてスケールしやすい
読み取りの96%をエッジで完結させ、レイテンシと費用を削る
読み取りが大半を占めるセッションデータは、世界各地のエッジに自動分散されるCloudflare KVと極めて相性が良い。
セッション参照をWorkersと同じ基盤のKVへ移せば、参照レイテンシは数ミリ秒台に縮む。東京への拠点間通信も消える。接続数の上限やコネクションプールの設計に悩む必要もない。
費用差は圧倒的だ。現行のアクセス量なら、KVの利用料は月額2,000円前後に収まる。管理画面や決済など即時性が必須の操作を除き、一般ユーザーの参照系をKVへ逃がすだけで、インフラ費用を月額約20万円削減できる計算になる。大きい。
4. 移行にあたっての課題 / 5. 移行方針案
Cloudflare KVはRedisの直接的な代替ではない。特に、KVは結果整合性を前提とするため、更新内容がすべての拠点へ即座に反映されるとは限らない。この違いはセッション管理の安全性に影響する。
想定される論点は次のとおりである。
- ログアウトや権限変更が別拠点へ反映されるまで、古い状態が参照される可能性がある
- 同じセッションに対する短時間の連続更新や同時更新に向かない
- 障害時にRedisへ戻すための切り戻し手順が必要になる
最大の壁は「結果整合性」によるログアウト遅延
ただし、RedisをそのままKVへ置き換えるわけにはいかない。KVは結果整合性を前提としている。書き込んだ内容が全世界のエッジへ行き渡るまでに、最大60秒の伝播遅延が生じる。
急所はログアウトだ。ユーザーがログアウト操作を行っても、別地域のエッジでは最大1分間、古いセッションが有効に見え続けてしまう。権限剥奪やアカウント停止でも同じことが起きる。危険だ。
この課題には、データの性質に応じた分割で対処したい。
- 一般セッションの参照: KVに配置（反映遅延を許容）
- 強制ログアウト・権限剥奪: セッション世代番号をDurable Objectsで保持し、整合性を担保
- 有効期限の更新: アクセスのたびに書き換えず、固定有効期限とトークン再発行へ仕様変更
すべてをひとつのDBでまかなう必要はない。大半の参照はKVで高速に捌き、重要な失効判定だけを強整合性の仕組みでガードする。このハイブリッド構成が最も現実的だ。
6. 今後の進め方 / 7. 提案
次の順序で検証を進めたい。
- 現行セッションの項目、サイズ、TTL、更新頻度、アクセス量を調査する。
- 即時整合性が必要な操作を洗い出す。
- KVへ保存するデータと、別の仕組みに残すデータを分類する。
- 検証環境で読み取り遅延、更新反映時間、失効処理、コストを測定する。
Cloudflare KVへの移行検討は進める。ただし、RedisをそのままKVへ置き換えるのではなく、セッションの読み取り特性と整合性要件を確認したうえで対象を限定する。まずは小規模な検証を行い、性能、コスト、安全性を評価する。その結果を基に適切かを判断したい。
4週間の二重書き込み検証から始める
安全を最優先にし、まずは本番影響のない低リスクなAPIから、4週間の概念実証（PoC）を進めたい。
- 二重書き込み: アプリケーション層でRedisとKVの双方にセッションを書き込み、データの欠落がないかログで照合する（読み取りは現行のRedisを維持）。
- 遅延と反映の計測: 東京・北米・欧州の主要拠点から、ログイン直後の読み取り遅延とログアウト反映時間を実測する。
- 段階的な参照切り替え: 社内アカウント ➔ 1%の一般トラフィック ➔ 全体へと段階的にKV参照へ切り替える。問題が生じた場合は設定フラグ1つでRedis参照へ即座にロールバックできる状態を保つ。
PoC期間中の実測値をもとに、ログアウト遅延の許容度とコスト削減効果を再評価し、本番全面移行の可否を判断したい。来週の定例で方針合意を取り、検証実装に着手したいと考えている。
v1.5.0 の進化: 「2段階ゲート」の搭載
表層の静的チェック（lint）だけでは絶対に届かない領域を、客観ルーブリックで解決する。
形態素解析（sudachipy）による lint.py が、禁止語・翻訳調・構文の単調さを決定論的に検出します。
※ ただし、lint が 0 件になっても「ダラダラ長い文」や「誰の実感もない冷たい文」は普通に残ります。
Phase 1 を通過した文章を、6軸の客観ルーブリックで自己採点。合格ライン（全軸90点以上）に届くまで自ら改稿を繰り返します。
※ 「前置きの削り」「生々しい実話の接地」を自律的に行い、収束させます。
判定に使われる6つの評価軸
合格条件: 全軸 90 点以上、かつ総合平均 92 点以上
脱AI臭・文体の自然さ
プレゼン的数宣言（「軸は2つあります」）、翻訳調ダッシュ（「——つまり〜——」）、自己啓発的決め文の根絶。
情報密度・簡潔さ
読者の時間を奪うダラダラとした前置き、誰もが知る前提の講釈、言い換えによる文字数水増しをバッサリ削る。
機能性・走査性
見出しを読めば結論が分かり、コピーしたいコードやコマンドに迷わず最短で辿り着けるか。
論理の明晰性と納得感
「なぜそうなのか」の因果関係が腑に落ちるか。抽象論だけでなく、実測データや具体例で接地しているか。
人間味・誠実さ（体温）
無菌室病の防止。「何にうんざりして作ったのか」「どこで実際に困ったのか」という書き手の生々しい実感（Why）を宿らせる。
自己証明力
その文書そのものが、掲げている主張（自然さ、明晰さ）の最高のお手本になっており、看板に偽りがないか。
導入と使い方
Claude Code, Cursor, ChatGPT, Codex など主要エージェントに対応。
npx skills add coji/natural-japaneseエージェントの設定ディレクトリへ自動インストール。
npx openskills install coji/natural-japanese
npx openskills syncAGENTS.md を介してあらゆるエージェントで利用可能。
導入後は特別なコマンドを意識する必要はありません。普段通りエージェントに指示を出すだけで、新ハーネスが自動起動します。
/natural-japanese score document.md