Claude Codeに頼むだけで、テキスト整形はどこまでできる？

「正規表現 \s+」を覚える必要はありません。CSVをJSONに変換するスクリプトを書く必要もありません。Windows環境でClaude Codeに日本語で指示を出すだけで、テキスト整形の大部分は進みます――ただし「大部分」であって「全部」ではありません。どこまで頼むだけで済むのか、どこから人の目が必要になるのか、5つのStepで確かめます。

この記事で確かめること

テキスト整形とひと口に言っても幅があります。今回は、Windows環境でClaude Codeに日本語で指示を出し、以下の5段階を順に検証します。

基本的なテキスト整形（空白削除・改行整理・全角半角変換）
データ形式の変換（CSV、TSV、JSON、Markdown表）
複数ファイルの一括整形
日本語テキスト特有の整形（句読点・スペース）
修正指示による改善

「正規表現を覚えなくても、自然言語で頼むだけでどこまで片付くのか」を5つのStepで確かめます。すべてWindows 10/11前提です。

前提（始める前に）

この記事の内容を試すには、Windows 10または11でClaude Codeが使える状態が必要です。Claude Codeの導入方法そのものはこの記事では扱いません。

まだClaude Codeを入れていない場合は、導入手順の記事を先にどうぞ。以降の検証は、Windowsのターミナル（PowerShellまたはコマンドプロンプト）からClaude Codeを起動している前提で進めます。

検証には、意図的に汚したテストデータを使います。

全角と半角が混在した文字列（例：「ＡＢＣabc　123」）
改行がバラバラなコピペ文章
カンマ区切りとタブ区切りが混ざった表データ
句読点が「、。」と「，．」で混在している日本語文章

こういうデータを用意しておけば、整形のBefore/Afterがはっきり分かります。手元に似たような汚いデータがあれば、それを読み込ませても構いません。

Step 1: 基本的なテキスト整形に頼んでみる

最初の依頼は、シンプルなテキストのクリーンアップです。

ファイルに保存された汚いテキストを読み込ませて、余分な空白を削除し、改行を整理し、全角英数字を半角に統一するよう頼みました。具体的な依頼文の要点は次の通りです。

data/sample.txt を読んで、余分な空白を削除し、連続する改行を1つにまとめ、全角英数字を半角に変換して上書き保存して

結果はまずまずでした。余分な空白の削除と連続改行の圧縮は一発で正しく処理されました。全角英数字の半角変換も、アルファベットと数字については問題なし。

ただし全角カタカナの半角変換は落とし穴でした。依頼文で「カタカナはそのまま」と指定していなかったため、意図せず半角カタカナに変換されてしまいました。Claude Codeの判断としては間違いではありません。指示が甘かっただけです。

確認のポイント:
– 全角→半角の変換対象にカタカナを含めるかどうかは、依頼時に明示すべき
– 変換後のファイルを開いて、視覚的に違和感がないか目で確認する

初心者ならここで止まりやすいポイントです。「全角を半角に」とだけ言うと、カタカナまで対象に入ってしまうことを予想しにくいからです。依頼文を少し丁寧に書けば防げる問題でした。

基本整形は指示次第で一発完了。ただし変換対象は人が明確に指定すること。

Step 2: データ形式の変換を頼んでみる

次に、データ形式の変換を試します。実務でよくある場面として、Excelからコピペした表データを別の形式に変換するケースを考えました。

用意したのは、カンマ区切り（CSV）の顧客データです。これをMarkdown表に変換するよう頼みました。

data/customers.csv を読んで、Markdownの表形式に変換して data/customers.md に保存して

変換結果は、列の数と内容が正しく保持されていました。ヘッダー行も適切にMarkdownの表記法に変換され、セル内のカンマもエスケープ処理されていました。

次に、逆方向の変換も試しました。Markdown表からJSONへの変換です。

data/customers.md の表を読んで、JSON配列形式に変換して data/customers.json に保存して

こちらも基本的には問題なく変換されました。ただし、元のCSVにあった空のセル（データ欠損）の処理で、JSONでは null と空文字列 "" のどちらにするかという選択があり、ここはClaude Codeの判断に任せた結果、null が入りました。データの使われ方によっては空文字列の方が都合が良いケースもあるため、ここは確認が必要なポイントです。

確認のポイント:
– 列の数が変換前後で一致しているか
– 空セルの扱い（nullか空文字か）が意図通りか
– 文字コードがUTF-8で保存されているか

CSVやJSON、Markdown表の相互変換は頼むだけで正しくできる。空データの扱いと文字コードだけ確認を。

Step 3: 複数ファイルの一括整形を頼んでみる

ここから少し実務寄りの検証です。ディレクトリ内にある複数のテキストファイルを一括で整形できるかを試します。

data/ フォルダに5つのテキストファイルを置き、すべてのファイルに対して「行末の空白を削除し、タブをスペース2つに変換し、最後に空行を削除する」という処理を頼みました。

data/ フォルダ内のすべての .txt ファイルに対して、行末の空白を削除し、タブをスペース2つに変換し、最後に空行を削除して、それぞれ上書き保存して

5つすべてのファイルが処理され、指定した3つの整形内容はどのファイルでも正しく適用されていました。

ここで気になるのは、もっと複雑な条件の置換です。たとえば「特定のパターンに一致する行だけを書き換える」という処理を、正規表現を使わずに自然言語で指示できるか。

data/ フォルダの各ファイルで、「TODO:」で始まる行の先頭に「[未]」を付けて

これも一発で正しく処理されました。正規表現の知識がなくても、「TODO:で始まる行」という自然言語の指定で十分伝わります。

ただし、ファイル数が多くなると（数十〜数百）、すべてのファイルの結果を目視で確認するのは現実的ではありません。サンプリングして数ファイルを確認するか、処理前後の差分を一覧で出力させるよう頼むと良いです。

確認のポイント:
– 処理対象のファイルが漏れなく含まれているか
– 処理後のファイル内容に意図しない変更がないか
– 大量ファイルの場合、サンプリングでの確認手法を考える

一括整形も自然言語の条件指定も頼むだけで動く。ただし全件確認は現実的ではないので、確認方法を工夫すること。

Step 4: 日本語テキスト特有の整形を頼んでみる

日本語のテキスト整形は、英語圏のツールでは対応しきれない領域です。Claude Codeが日本語の文脈をどこまで理解して整形できるかを確かめます。

まず、句読点の統一から。「、。」と「，．」が混在している文章を「、。」に統一するよう頼みました。

data/japanese.txt の句読点をすべて「、」「。」に統一して保存して

基本的な句読点の置換は問題なく完了しました。文末の「．」や途中の「，」が正しく「。」と「、」に変換されていました。

次に、もう一つ日本語特有の課題として、助詞の後のスペース挿入を試しました。

data/japanese.txt で、助詞（は、が、の、に、を、で、と、へ、も、まで、から、より）の後にスペースがない場合、スペースを入れて読みやすくして

ここは結果がやや微妙でした。単純な文では助詞の後にスペースが挿入されましたが、複文や長い文になると、どこまでが助詞の「後」に当たるかの判断がブレる場面がありました。たとえば「〜については」の「は」の後ろにスペースが入るのは自然ですが、「についてはじめた」の「は」は助詞ではなく動詞の一部なのにスペースが挿入されるケースがありました。

日本語の文脈判断が必要な整形は、まだ人が確認する余地が大きい領域です。

確認のポイント:
– 句読点の変換漏れがないか
– 助詞の判定が正しいか（同音異義の漢字や動詞の一部との区別）
– 文脈によっては不要なスペースが挿入されていないか

句読点の統一は頼むだけでできる。ただし文脈判断が絡む処理（助詞の判定など）は、今のところ人が確認する必要がある。

Step 5: 修正指示で改善する

どの段階でも、初回の一発で完璧な結果が出るとは限りません。ここでは、Step 4で生じた助詞判定の誤りを修正指示で直せるかを試します。

Step 4の結果を確認したあと、次のような修正指示を出しました。

「についてはじめた」の「は」は助詞ではなく動詞の一部なので、この部分のスペースは削除して。同様に、動詞の活用の一部になっている「は」「が」「に」の後ろのスペースも削除して

修正後の結果、指摘した箇所は正しく修正されました。ただし、別の長い文で新たに同じパターンの誤判定が見つかりました。追加で同じような修正指示をもう1回出して、最終的にすべての誤判定が解消されました。

このように、一発で完璧でなくても、対話で問題を指摘すれば改善されていきます。今回のケースでは計3回のやり取り（初回依頼＋修正指示2回）で望む結果に到達しました。

一発ではうまくいかなかった点を整理すると:
– 助詞の判定は、日本語の形態素解析レベルの精度が求められるため、自然言語の指示だけでは限界がある
– 長文になるほど誤判定の確率が上がる
– 修正指示を繰り返せば品質は上がるが、すべての誤りを検出するには最終的に人が通読する必要がある

修正指示は確実に効く。ただし日本語の文脈に依存する問題は、直すたびに別の場所で再出現する可能性がある。最後は人が通読して総合的に確認すること。

どこまで頼むだけでできた？

5つのStepを通じて分かったことを整理します。

頼むだけでできたこと:
– 余分な空白の削除、連続改行の圧縮
– 全角英数字→半角への変換（カタカナを除く指定があれば完璧）
– CSV、TSV、JSON、Markdown表の相互変換
– 複数ファイルへの同一ルールの一括適用
– 正規表現を使わない自然言語による条件指定（「TODO:で始まる行」等）
– 日本語の句読点統一

頼むだけでは到達しなかったこと:
– 日本語の文脈判断を要する整形（助詞と動詞活用の区別など）の一発での完璧な処理
– 処理結果の全件自動検証（人がサンプリング確認する必要がある）
– 大量ファイルの整形結果の全件品質保証

人が確認・修正すべきだったこと:
– 全角→半角の変換対象の明示的な指定
– データ変換時の空セルの扱い（nullか空文字か）
– 日本語テキストの助詞判定結果の通読確認
– 処理後のファイルの文字コード確認
– 大量ファイルのサンプリングによる品質確認

今回の検証全体でのやり取り回数は、5つのStepと修正指示を合わせて計8回でした。

振り返り

Claude Codeに頼むだけでテキスト整形の大部分は進みました。

基本的な整形（空白・改行・全角半角）とデータ形式の変換は、依頼文を丁寧に書けば一発で期待通りの結果が出ます。複数ファイルへの一括処理も、自然言語の条件指定で十分機能しました。日本語テキストの文脈に依存する処理だけが、現状では人の目による確認が必須です。

Step 1〜3（基本整形とデータ変換）は、Windows環境でClaude Codeが動いていればすぐ試せます。Step 4の日本語テキスト整形は、結果の良し悪しを判断するための日本語の知識が必要になるため、少しハードルが上がります。

頼むだけでここまでは進められた。ただし最後は人が確認する、というのが今回の結論です。

次に試すなら

テキスト整形ができることが分かったので、次はもう少し応用範囲を広げてみると良いです。

たとえば、整形したデータをWordPressに投稿するMarkdownの生成や、ログファイルからの特定パターンの抽出、HTMLファイルのタグ整理などが考えられます。どれも「自然言語で指示するだけ」という同じアプローチで進められます。

テキスト整形以外にも、Claude Codeに頼むだけでどこまでできるかを検証した記事を他にも用意しています。興味があれば併せてどうぞ。

コツを一つだけ。頼むときは「何を」「どうしてほしいか」を具体的に書くほど、結果が安定します。「適当に整形して」より「空白を削除して、全角英数を半角にして」と指示する方が、意図通りに進みやすいです。

まとめ

空白削除・改行整理・全角半角変換のような基本整形は、自然言語の指示だけで実務レベルの結果が出ます。CSVやJSONの形式変換、複数ファイルへの一括処理も同じです。

ただし「全部」ではありません。日本語テキストの文脈判断を要する整形や、大量ファイルの最終品質確認は、今のところ人の目が必要です。

正規表現を覚えなくても、スクリプトを書かなくても、日本語で「どうしてほしいか」を伝えるだけでここまでは進められました。最後は人が確認する、という境界線を意識しておけば、テキスト整形の負担は大きく減らせるはずです。

Claude Codeでどこまでできる？