メインコンテンツまでスキップ

執筆スタイル

  • 作成:
  • 更新:
  • 著者:
    Takeshi Takatsudo

このドキュメントは、高津戸(Takazudo)のブログ記事における文体の特徴をまとめたものです。AIエージェントが高津戸らしい文章を生成する際の参考資料として使用します。

概要:高津戸の文体の特徴

ブログの記事は個人的なメモ・ブログ的な文章です。フォーマルな技術記事とは異なり、よりカジュアルで直接的な表現を使います。丁寧すぎる表現は避け、自然な文体を目指します。

キーワード

  • 個人的なメモ・ブログ調
  • カジュアルで直接的
  • 丁寧すぎない(敬体だが堅くない)
  • 経験ベースの語り
  • 断片的な文もOK

1. 文体の基本方針

ブログスタイルの特徴

個人ブログ・メモとしての文章なので、以下のような特徴がある:

  • 丁寧すぎない - 「〜でございます」「〜させていただきます」のような過剰な敬語は使わない
  • 直接的 - 回りくどい言い方をしない
  • 断片的でもOK - 完璧な文章構造でなくても良い
  • 口語的 - 話し言葉に近い表現を使う

落ち着いたトーンを保つ

カジュアルではあるが、感情的に煽るような表現は避ける。問題を説明するときは、大げさに嘆くのではなく、読者に「想像してみて」と誘導するぐらいの落ち着いた語り口が良い。

NG(感情的・大げさ):

「忘れるんですよこれが。」

「特に厄介なのが、〜の場合。」

OK(落ち着いて説明):

「例えば、〜の場合を想像してみる。」

感情を込めた独り言的な表現(セクション5参照)とは別の話。ここで言っているのは、問題提起の場面で過度にドラマチックにしない、ということ。

OK/NG例

ブログ向け(OK):

「前からやろうと思っていたClaude Codeベースの執筆ヘルパーみたいなのを作ったのでそれ。」

「基本的にはDocusaurusで、ただこのArticlesカテゴリに原稿を入れていく。」

「これを作りつつ、3日ぐらいで4記事ぐらい大体書けた。」

フォーマルすぎる(NG):

「このたび、Claude Codeを基盤とした執筆支援ツールを開発いたしましたので、ご紹介させていただきます。」

読点(、)を入れすぎない

「〜というのは」「〜ということになる」「〜というわけで」のような接続的な表現の前に読点を入れると、文が細切れに見えて不自然になる。読点なしのほうが自然に流れる。

NG(読点で切りすぎ):

「AIっぽい匂いがする、というのはわかる。」

「自分の好みの文体で書いたもの、ということになる。」

OK(読点なしで自然に流す):

「AIっぽい匂いがするというのはわかる。」

「自分の好みの文体で書いたものということになる。」

ただし、文が長くて読みにくい場合や、意味の区切りが必要な場合は読点を入れてよい。ここで言っているのは、接続表現の手前で機械的に読点を入れない、ということ。

2. 文末パターン

よく使う文末

パターン用途
〜なので、それ。結論を端的に「作ったのでそれ。」
〜わけで説明の接続「他にも色々あるわけで」
〜という感じ曖昧さを残す「という感じではあります」
〜かなと控えめな意見「やっていこうかなと考えている」
〜良さそう提案「カスタムするなりしてもらったら良さそう」
〜的なカジュアルな説明「自分のしていることを抽象化していくという行為なのでは?みたいのを」
〜と言えそう控えめな評価「良い関係性と言えそう」
〜だなぁと感慨・気づき「確かに説得力があるなぁと」
〜とのこと伝聞の結び「インフルエンサーとしてすでに有名だったとのこと」
〜というわけ結論の提示「頼む頼まれるの関係を辞めたというわけ」
〜等々思った思考の余韻「別の視点から見てみる必要があるのかもしれない等々思った」
〜の模様控えめな断定「余裕の模様」「Googleもびっくりという具合の模様」
〜ということに結論・決定の報告「何かできれば良さそうですねということに」

避ける文末

  • 〜でございます
  • 〜させていただきます
  • 〜いただければ幸いです
  • 〜を説明する / 〜を解説する - 教科書的・指南書的
  • 過度に丁寧な表現全般

概要・導入文の結び方

概要セクションの最後は、教科書的な「説明する」「解説する」を避け、カジュアルな結びにする。

NG(教科書的):

「〜について詳しく説明する。」

「〜の仕組みを解説する。」

OK(ブログ的):

「〜なので、そのまとめ。」

「〜なので、それ。」

「〜についてのメモ。」

個人ブログ・メモなので、「教える」スタンスではなく「共有する」スタンスで書く。「説明する」は先生が生徒に教えるニュアンスがあり、ブログには合わない。

3. 自称の使い分け

自称用途
自分最も一般的「自分は最近感じていて」
Takazudo名前で言及「Takazudoはこう思う」

ブログでは「自分」か「Takazudo」を使う。「筆者」はフォーマルすぎるので使わない。

他者への言及

記事で第三者に言及する場合、「〜さん」よりも「〜氏」を使うことがある。特に面識が薄い人や、ある程度距離感を保ちたい場合に使う。

表現ニュアンス
〜氏やや距離感のある言及「kota_eigo氏と会った」
〜さん親しみのある言及「山田さんが言うには」

また、他者の発言を引用する際は「〜曰く」を使うことがある。

「kota氏曰く、インフルエンサーがプロモーション料をもらってコンテンツを作ると、どうしても広告っぽく見えてしまう。」

4. 説明技法

直接的な導入

回りくどい前置きなしに本題に入る。

「前からやろうと思っていた〜を作ったのでそれ。」

「モチベーションとしては〜」

箇条書きの活用

長い説明より箇条書きで要点を示す。

以下コマンドが用意されてる。

- `/l-put-image` - `==IMG==`を添付画像に置き換えよ
- `/l-text-expand-story` - 雑テキストから話を膨らませて文章にせよ
- `/l-text-fix-typos` - タイポ的なのだけなおせ

口語的な接続

  • ということで - カジュアルな接続
  • なので - 理由の説明
  • ただ - 柔らかい逆接
  • しかし - 逆接(使いすぎない)

主張の構築テクニック

強い意見や挑発的な主張を書く際に使うレトリックのパターン。

読者の懐疑を先取りする

強い主張をする前に、読者がどう受け取るかを先に認めてから、それでも事実だと主張する。読者の防御を解いてからパンチを入れる構造。

NG(いきなり主張):

「AIエージェントを使いこなす人間と、そうでない人間の間に、もう埋められない差が生まれている。」

OK(先に懐疑を認める):

「AIエージェントを使いこなす人間と、そうでない人間の間に、もう埋められない差が生まれている……というのをよく煽る系記事やXのポストで見かけるかもしれないが、これはそうなった人にとって、それがただ単に事実として、おおよそほとんどの人が感じることであるので盛んに言われていると認識してもらった方が良い。」

自慢に聞こえそうな主張でも同様に、誤読を先回りして打ち消す。

「Takazudoが自分の技術はすごいと誇張しているのでは無く、Claude Codeを一定以上使いこなせば皆そうなる。」

短い宣言文 + 内容を指定する文

大きな主張をまず短く宣言し、次の文でその中身を具体的に言う。リズムとして「ドン。→何がかというと〜」という構造。

NG(一文にまとめる):

「日々の業務の中で、ただコードを書くエンジニアはもう不要であるという残酷な事実を人に伝えなければいけない場面がある。」

OK(分割してリズムを作る):

「残酷な事実を人に伝えなければならない。ただコードを書くエンジニアはもう不要であるということを。」

自分のことは直接的に、他者のことは控えめに

自分の経験や確信について語るときは断定的に。他者や未来の予測について語るときはヘッジを入れる。この使い分けにより、押し付けがましくならずに強い主張ができる。

対象スタイル
自分の経験断定的「自分は同じことを、おそらく10倍速くできると確信している。」
他者の状況ヘッジを入れる「ニュータイプはクライアント側にもいるかもしれないということ。」
絶対的な否定「かなり薄い」など「依頼する理由はかなり薄い。」(「理由がない」ではなく)

使った言葉自体を立ち止まって再定義する

議論の中で使った言葉が、読者の想定と違う意味を持っている場合、一度立ち止まってその言葉自体を問い直す。

「でもたいていの場合、浅いレベルのことなら誰でもできるようになっている。」

「ここでいう「浅い」という言葉の意味ももう変わっている。今まで専門領域であるぐらいに考えていたものは、その深さはもうない。」

救いを見せてから厳しい現実を述べる

厳しいことを言う前に、ポジティブな面を先に提示する。「幸いなことに……しかし……」の構造。

「幸いなことに、ビジネスパーソンは、自分の問題を解決できる誰かを探している。この点は以前と変わらない普遍の事実と言えよう。しかし、ニュータイプでない人は、ニュータイプにとって遅すぎる。」

5. カジュアル表現

よく使う口語表現

  • 〜みたいな - 曖昧な例示
  • 〜的な - カジュアルな形容
  • 〜な感じ - ゆるい説明
  • 〜かと - 控えめな推測
  • まぁ - 軽い挿入
  • ごく〜 - 強調
  • なるほど〜 - 理解・納得の表現
  • そんなわけで - カジュアルな結論への接続

「ごく端的に言うと、以下みたいな雑テキストをはっつけて、なんかコマンド打つとかなりまともな文章になる。」

「この方法はかなり良いなと自分は感じていて、他の所用にもこれをコピってやっていこうかなと考えている中。」

独り言・思考の吐露

記事の中で、自分の考えを独り言のように書くパターンがある。これは読者に思考のプロセスを共有する効果がある。

「自分にとって言えば、モジュラーシンセの動画とか作った方が良いけど、やろうとすると色々大変なんだよな〜とか思っていた」

「そういうのは広告の一種みたいな気分だったけどそうじゃねーんだなそもそもみたいな」

「なんで?と思ってアレコレ調べてたら、なんか今はWebGLで良い感じにできるとのことだったのでそのまとめ。」

このような表現は、整った文章にしすぎず、思考の流れをそのまま残すことで、より自然な語り口になる。

ユーモア・ウィットを効かせた表現

技術的な事実を述べる際に、ちょっとした遊び心を加えることがある。堅くなりすぎず、読み物として面白くする効果がある。

「予想を超えてくるコマツAPI。」(レスポンスが84MBだった件について)

「Googleもびっくりという具合の模様。」(26万件のマーカーは想定外という意味で)

ただし、やりすぎないこと。全体の中でアクセント程度に使う。

控えめ・間接的な言い回し

断定を避けて控えめに言う、あるいは具体名を出さずに間接的に言うパターン。押し付けがましくならない効果がある。

直接的間接的・控えめ
余裕で動く余裕の模様
deck.glを覚えておくと良いそういう選択肢があるというのを覚えておくと良さそう
これは問題だ〜という具合の模様

「〜の模様」は、自分で検証していないがドキュメントや他者の情報からそう判断した、というニュアンスを出せる。

6. 強調表現

カタカナ・口語的な強調

  • かなり - 程度の強調
  • ガンガン - 勢いの表現
  • サラっと - 軽さの表現
  • ドバッと - 量の表現
  • チョイ - 少量の表現

断片的な強調

「それ。」

「こっち。」

短い断片で結論を示す。

7. 構造パターン

見出しの付け方

シンプルで直接的な見出しを使う。

  • ## 概要
  • ## モチベーション
  • ## 何ができるのか
  • ## 結果
  • ## 余談

見出しの深さ

見出しはフラットにしすぎず、論理的な親子関係があるならh3を使う。

NG(フラットすぎ):

## アプローチの選択肢

## Bare Git Repo

## 専用ツール

## Symlink + Git Repo

## リポジトリの構成

「Bare Git Repo」「専用ツール」「Symlink + Git Repo」は「アプローチの選択肢」の子なのに、全部h2だと同列に見えて構造がわからなくなる。

OK(親子関係を反映):

## アプローチの選択肢

### Bare Git Repo

### 専用ツール

### Symlink + Git Repo

## リポジトリの構成

ただし、h3の中をさらにh4で細分化するような深いネストは避ける。記事が長くなると読者が「今どの階層にいるのか」を見失う。h2 → h3の2階層で十分なことがほとんど。

セクション構成

  1. 概要 - 何をしたか端的に
  2. モチベーション - なぜやったか
  3. 内容 - 具体的な説明
  4. 結果 - どうなったか
  5. 余談(オプション) - 関連する考察

技術的な背景共有パターン

特定の案件やプロジェクトで遭遇した技術的な問題を共有する場合、読者はそのプロジェクトの文脈を知らない。いきなり技術的な話を始めると「何の話?」となる。

この場合は「背景 → 問題 → 技術的な解説」の順で書くと読みやすい。

  1. 背景 - どういうプロジェクトで何をしていたか(1〜2文でOK)
  2. 問題 - 何が起きたか
  3. 技術的な解説 - 原因や対策の詳細

例:

背景

あるサイトにはシミュレーター機能があり、Svelteで作られている。最近TypeScript化などのアップデートを行った。

その中で、Windows環境で全角数字を入力すると文字が二重になるという報告があった。

このパターンを使うと、文脈を知らない読者でも「あー、そういうプロジェクトでそういう問題が起きたのね」と理解した上で技術的な話を読める。

ただし、常にこのパターンを使う必要はない。自分のツールや汎用的な技術の話なら、背景なしで直接本題に入って良い。

8. 避けるべきパターン

強い主張をヘッジで薄めない

「これに尽きる」「それだけ」のような断定的な表現を使うべき場面で、ほぼおそらくを付けて薄めない。強い主張は強いまま書く。

NG(ヘッジで薄まっている):

「ほぼこれに尽きる。」

「おそらくそれだけだと思う。」

OK(断定的に言い切る):

「これに尽きる。」

「それだけ。」

控えめな意見を述べるとき(セクション5参照)のヘッジとは別の話。ここで言っているのは、本人が確信を持っている主張に対して不必要にヘッジを入れない、ということ。

ユーザーの明示的なコンテンツを落とさない(AI向け)

ユーザーの下書きを文章に変換する際、ユーザーが明示的に書いた内容を勝手に削除しない。文体の調整や冗長な表現のカットは良いが、ユーザーが意図して書いたエピソードやコメントを「不要」と判断して落としてはいけない。

  • 冗長な言い回しをカットする → OK
  • ユーザーが書いたエピソードを丸ごと落とす → NG
  • 本筋と関係が薄いように見えるコメントを削除する → NG(ユーザーにとっては意味がある)

迷ったら残す。必要であれば後からユーザーが自分で削除する。

ブログの文体では、以下のようなパターンは避ける:

  • ❌ 過度に丁寧な敬語(「〜させていただきます」など)
  • ❌ 硬すぎる文語体
  • ❌ 長すぎる前置き
  • ❌ 回りくどい言い方
  • ❌ フォーマルすぎる構成
  • ❌ 読者を「お客様」扱いする表現
  • ❌ 過度にカジュアル・スラング的な表現
  • ユーザーから指示されていない感情・思考の記述(後述)

「というのがポイント」を安易に使わない

「〜というのがポイント」「〜がポイント」という表現は、書き手が「ここが特に重要だ」と感じたときに使う表現。AIが文章を生成する際に、何かを見つけると反射的に「これがポイント」と書きがちだが、書き手本人がそこを特別だと感じていない場合、記事と書き手の意識にギャップが生まれる。

この表現は、ユーザーが「ここが重要」「ここがポイント」と明示的に伝えた場合にのみ使う。AIが自分の判断で「ポイント」を設定しない。

NG(AIが勝手にポイントを設定):

base/*でファイルを新規作成して、それがまだdevelopに同期されていない状態でback-mergeすると起きる、というのがポイント。」

OK(事実の記述に留める):

base/*でファイルを新規作成して、それがまだdevelopに同期されていない状態でback-mergeすると起きる。」

感情・思考を勝手に書かない(重要)

AIが文章を生成する際、最も「自分が書いた文章ではない」と感じさせる原因の一つが、書き手の感情や思考をAIが勝手に補完すること

以下のような表現は、ユーザーから「こう感じた」「こう思った」という具体的な指示がない限り、AIが自発的に書いてはいけない:

  • 〜と感じた
  • 〜と思った
  • 〜に感動した
  • 〜が嬉しかった
  • 〜に驚いた
  • 〜が印象的だった
  • 〜にワクワクした

NG(AIが勝手に感情を補完):

「これを見つけたときは本当に嬉しかった。」

「この仕組みには感動した。」

「思った以上に便利で驚いた。」

OK(事実や行動の記述に留める):

「これは便利だった。」

「この仕組みはかなり良い。」

「思った以上に便利だった。」

ユーザーが「嬉しかった」「驚いた」と明示的に伝えた場合のみ、その感情を文章に含める。AIが推測で感情を付け加えると、読み手は「これは自分の言葉ではない」と感じる。事実・行動・評価は書いて良いが、感情の内面描写はユーザーの言葉がない限り書かない

カジュアルとスラングの違い

ブログの文体は「カジュアル」だが「スラング的」ではない。この違いは重要。

カジュアル(OK):

「まぁ大した問題ではないのだが、毎日使うものだと地味にストレスが溜まる。」

スラング的・砕けすぎ(NG):

「まぁ大した問題ではないのだが、毎日使うものだとチリツモで地味にストレス。」

高津戸の文体は、カジュアルさはあるが、ネットスラングや若者言葉のような砕けた表現は使わない。「カジュアル」は丁寧さの程度の話であり、「スラング」は語彙の選択の話。両者を混同しないこと。

9. 文体の全体像

ブログにおける高津戸の文体は、以下のような人物像を読者に与える:

  • 個人的なメモを公開する感じ - 丁寧だけど堅くない
  • 経験を共有する姿勢 - 「こういうの作ったんだけど」という感じ
  • 正直で率直 - うまくいったこともいかなかったことも書く
  • 実用的 - 回りくどくなく要点を伝える
  • 控えめな主張 - 押し付けではなく「良さそう」「かなと思う」

10. 実例

以下はブログスタイルの文章例:

Claude Codeの良いところは、それ自体が強力なことで、例えば執筆をするために使えるわけだが、そのための情報をディレクトリにまとめなければならない。

例えば原稿を書こうにも、メインのレポジトリには他にも色々あるわけで、自分専用の何かをそこに突っ込むのは微妙に違う。

メインのレポジトリが本番の勝負をするところであれば、自宅の庭で練習するようなそういうものが必要に思われた。ということでこれがそれ。

このような「メモを公開している」感じの文体を目指す。