DEV Community: Koji M

jpomop: open code to convert Japanese DPC inpatient data to OMOP

Koji M — Tue, 13 Oct 2026 07:03:41 +0000

Japan has a standard format for some inpatient data called DPC. Many people in the OHDSI world use the OMOP Common Data Model. I could not find public code that connects the two, so I started writing it. The project is called jpomop, and the code is on GitHub: https://github.com/kojikojikojikoji/jpomop

I am a Japanese data scientist, and I live in London.

Why DPC data matters

DPC is used to classify acute inpatient stays and help set hospital payments in Japan. Hospitals in the system send standard files about each stay to the Ministry of Health, Labour and Welfare (MHLW). The ministry publishes the file layout every year in a long manual. The FY2026 edition has 244 pages (MHLW, PDF).

The scale is large. The MHLW summary of the FY2024 discharged patient survey lists 1,767 DPC hospitals in the analysed data (MHLW, PDF). Other hospitals also take part in the survey. Every hospital in the survey makes its files from the same manual for that year.

jpomop reads two of those files. Form 1 (様式1) holds details about the patient and stay, with diagnoses coded in ICD-10. The EF file (入院EF統合ファイル) records billed services by day, including drugs and procedures, and ward information.

Why OMOP

The OMOP CDM is an open community standard for observational health data. The OHDSI CDM Working Group manages it (OHDSI).

In Europe, EHDEN says it has a network of over 100 data partners mapped to the OMOP CDM (EHDEN). In England, the NHS Research Secure Data Environment Network agreed in 2023 to adopt the OMOP CDM (HDR UK).

OMOP is used in many places where I would like Japanese data to be usable. Putting DPC data into OMOP tables is a first step toward using OHDSI tools and study code. Whether a study works also depends on the mappings and on what DPC records.

What was missing

I looked for open code that turns DPC files into OMOP tables. I did not find any. There is an open ETL for Japanese EHR tables from the Rinchu-net standard data tables (GitHub). Its source list does not include DPC files.

I wanted something anyone could run without real patient data. I wrote the converter from the public specification and tested it with synthetic data and the worked examples in the manual.

What jpomop does

This is the quick start from the README:

pip install -e .
jpomop synth --n 100 --out synth/
jpomop validate --yoshiki1 synth/yoshiki1.txt --ef synth/ef.txt
jpomop convert --yoshiki1 synth/yoshiki1.txt --ef synth/ef.txt --out cdm.duckdb
jpomop report --cdm cdm.duckdb

synth makes fake data for 100 patients. validate checks the files against the parts of the FY2026 specification that jpomop supports and lists the problems it finds. convert writes the CDM tables to DuckDB. report summarises the result.

The validation step can be useful on its own. It does not need OMOP or a vocabulary. A hospital that does not use OMOP could still use it to check the supported fields in its DPC files. I have not tried this on real files yet.

This table shows which OMOP tables jpomop writes from each input:

DPC	CDM table
Form 1, whole-stay form	person, visit_occurrence, observation_period
EF, ward code for each day	visit_detail
Form 1, non-suspected diagnoses (ICD-10)	condition_occurrence
EF, codes that start with 6	drug_exposure
EF, codes that start with 1	procedure_occurrence
Form 1, discharge outcome 6 or 7	death

That makes eight CDM tables. Patient IDs are hashed.

The manual tells hospitals to set the ward code for each service date, not the ward at discharge (page 193). jpomop makes one visit_detail row for each run of days on the same ward. The ward code is each hospital's own code.

The specification lives in YAML files. Each field has a name, a length, a type and the page number in the manual. I did not copy the manual's text.

The tricky parts

Suspected diagnoses. Japanese claims data often carry diagnoses marked as "suspected". In Form 1, this is the modifier code 8002. jpomop leaves these out of condition_occurrence and counts them. I made this choice to avoid treating them as confirmed diagnoses.

Dates. Form 1 has no date for each diagnosis, so jpomop uses the admission date as the condition start date. This matters for studies of when a condition began: admission may not be the start date. The EF file has a date for each service, so jpomop uses the recorded service dates for drugs and procedures.

Form types. Form 1 has several form types for one stay. jpomop uses the form for the whole stay. It uses the day-90 interim form only when a stay has no whole-stay form yet. Ward-group forms and readmission forms are counted but not converted. In the manual, a ward-group form covers part of a stay (page 42). A readmission form joins two stays, and each of those stays also has its own form (page 125). So their days are already in the forms that jpomop uses. I have not checked this on real files.

Diagnosis codes. DPC writes ICD-10 without a dot, and sometimes with a fifth character. jpomop tries the most specific Athena code first and then shorter ones. For example, S7200 becomes S72.00, then S72.0, then S72.

Drug mapping. The EF file uses receipt codes for drugs. jpomop looks up each code in the public drug master to get the NHI drug price code. Then it looks up that code in the table by Kimura et al. (2025), which maps Japanese drugs to RxNorm concepts (dataset, CC BY 4.0; paper). The table has 12,178 rows for oral and injectable drugs. It does not cover every drug. In the October 2026 drug master, 11,956 of 19,222 items have a concept ID in the table. That is 62% of the items, not of real drug use. I have not checked these concept IDs against Athena yet. Drugs that patients bring from home are left out.

Masters are not included. The code masters come from the Japanese body that reviews and pays health insurance claims. Its website terms prohibit using or reproducing its documents without permission. So the repository does not include them. Users download the masters, the Athena vocabularies and the Kimura table themselves. Then jpomop vocab build joins them on the user's own machine. Without a vocabulary, diagnosis and drug concept IDs are 0, and the original codes stay in the source value columns.

The repository has a PROVENANCE.md file. It lists every document used, with its version, URL, retrieval date and SHA-256 hash.

Status and honest limits

jpomop is early. The current version number is 0.0.1. Here is what is true today:

It reads and checks both files and writes eight CDM tables.
44 tests pass. Some of them rebuild the worked examples in the FY2026 manual.
I have tested it only with synthetic data and those manual examples.
I have not run it on real hospital data.
I have not measured mapping rates with a full Athena vocabulary.
Procedures keep their DPC code as the source value. Their concept ID is 0 for now.
It targets CDM v5.4. The OHDSI site now lists v5.5 as the current version.

Synthetic data shows that the code works on the cases I made. It does not show that it works on real hospital files. Errors such as double counting or wrong joins between Form 1 and EF may not show up until the code is tested on real data.

I plan to release v0.1 at the end of November 2026.

How you can help

I am looking for two kinds of people.

If you work with DPC data in Japan, I would like you to run jpomop inside your own environment. You do not need to share any data. Counts and error messages are enough. If my reading of the manual is wrong, I want to know.

If you work with OHDSI tools, I would like your view on the mapping choices. How should suspected diagnoses be handled? Is the admission date a fair start date for conditions? What would make Japanese inpatient data useful in your network studies?

Issues and pull requests are open on GitHub: https://github.com/kojikojikojikoji/jpomop

The code is under Apache-2.0. Mapping tables made by the project are under CC BY 4.0. This does not cover the masters, the Athena vocabularies or the Kimura table. They keep their own terms.

partworth: hierarchical Bayes for choice-based conjoint in Python

Koji M — Tue, 13 Oct 2026 07:02:35 +0000

A choice-based conjoint (CBC) study shows people a few products and asks them to pick one. Then it does this again and again. Each product is a mix of features, such as brand, size and price. From the choices, you estimate how much each feature matters to each person. Then you answer business questions. Which product wins? What happens if we raise the price? How much more will people pay for a bigger size?

A common method is hierarchical Bayes (HB). Many teams use Sawtooth CBC/HB for it. It is commercial and runs outside Python. So the work often looks like this: you estimate in one tool, export a file, and build a simulator in a spreadsheet. Each hand-off is a place for mistakes. The model's uncertainty is also often lost on the way, and the spreadsheet shows one share per product, with no range.

I wanted to do the whole thing in Python. Python already has general choice models. For example, pymc-marketing has a MixedLogit model. As of October 2026, it takes a wide table and has no correlations between coefficients. It also has no Sawtooth-style files and no WTP. For CBC work, I needed a few specific things:

a "none" option, for people who would buy nothing
correlated tastes, because people who care about brand may also care about price
a price coefficient that is negative for every respondent, so willingness to pay makes sense
outputs in the format CBC teams already use, like a Sawtooth-style utilities file
a market simulator that shows uncertainty

I could not find one Python package that did all of this, so I wrote partworth. It is open source (Apache-2.0) and built on PyMC.

What partworth does

The README splits the workflow into four steps.

Your survey. You bring CBC answers in long format, one row per respondent, task and alternative. You can also import a wide design, for example from ChoiceDesign.
Fit one model. ChoiceData checks the data. HierarchicalMNL runs HB estimation on PyMC. Then you get diagnostics: R-hat, effective sample size (ESS) and divergences.
Read the results. You get part-worths for each respondent, attribute importances and RLH (a fit score for each person). You can write a Sawtooth-style CSV file.
Answer business questions. You get market shares with credible intervals, price curves, and willingness to pay (WTP) for a feature.

Steps 1 to 3 replace the "estimate, export, spreadsheet" routine. Step 4 uses the posterior draws, so every share, price curve and WTP comes with a credible interval.

A few design choices are there because of how CBC data look. Each person usually answers only about 8 to 20 tasks, so the data for one person is thin. partworth uses a non-centred model, which usually samples better in this case. It puts an LKJ prior on the correlations between tastes. For price, you can add a sign constraint. Then the price coefficient is negative for every respondent, through a lognormal. Without this, a respondent whose price coefficient is near zero or positive gives a WTP that makes no sense.

A quick look

partworth needs Python 3.12 or later. It is not on PyPI yet, so you install it from GitHub:

pip install "partworth[nutpie,datasets] @ git+https://github.com/kojikojikojikoji/partworth"

On macOS 26 or later, PyTensor 3.3.3 or earlier can fail with ld: library 'd64' not found. Set PYTENSOR_FLAGS=cxx= to avoid it.

This is the Quick look example from the README. It uses simulated data, so you can paste it as it is.

import pandas as pd
import partworth as pw
from partworth.datasets import simulate_cbc

# 300 respondents, 12 tasks, 3 products + "none" per task.
# mu: true population means of the coded coefficients (price on the log scale).
data, truth = simulate_cbc(
    300, 12, 3,
    {"brand": ["A", "B", "C"], "size": ["S", "M", "L"], "price": [2.0, 2.5, 3.0, 3.5]},
    price="price", mu=[0.4, -0.1, -0.3, 0.1, -0.5, -1.0], sd=0.6, seed=1,
)
print(data.describe())                       # how often each level was shown and chosen

# more tuning and draws than the defaults: the SD of "none" mixes slowly (see the guide)
result = pw.HierarchicalMNL(data).fit(draws=2000, tune=3000, chains=4, random_seed=1)
print(result.diagnostics().report())         # R-hat, ESS, divergences, what to try

result.part_worths()                         # raw utilities, one column per level
result.part_worths("zc_diffs")               # zero-centred diffs
result.importances()
result.to_sawtooth_csv("utilities.csv")

scenario = pd.DataFrame({"product": ["Ours", "Theirs"], "brand": ["A", "B"],
                         "size": ["M", "M"], "price": [3.0, 2.5]})
sim = pw.MarketSimulator(result)
print(sim.shares(scenario))                  # shares with 90% credible intervals
print(sim.price_curve(scenario, product="Ours", grid=[2.0, 2.5, 3.0, 3.5]))
print(pw.wtp(result, attribute="size", from_level="S", to_level="L"))

simulate_cbc makes 300 fake respondents with known true values. The fit uses more tuning and more draws than the defaults. The SD of "none" mixes slowly in this example, and the user guide explains why. The last three lines answer the business questions. Each one prints an estimate together with its credible interval.

For real data, examples/camera.py runs the same steps on the public camera data from the R package bayesm. partworth downloads that data from CRAN on first use.

How I checked it

An HB package can give numbers that look fine and still be wrong. So the repository has validation scripts. Each script writes a report to validation/results/. These are the main results.

Comparison with R bayesm. I ran bayesm 3.1.7 (rhierMnlRwMixture) and partworth on the camera data. Tasks 1 to 14 were for estimation. Tasks 15 and 16 were kept as hold-out tasks.

For every coefficient, the respondent-level posterior means of the two packages correlate at 0.997 or more.
The hold-out hit rate is 0.729 for partworth and 0.730 for bayesm.

The two packages use different samplers and priors. bayesm uses random-walk Metropolis and an inverse-Wishart prior. partworth uses NUTS and an LKJ prior. Even so, the respondent-level posterior means move together very closely, and the two packages predict the hold-out tasks equally well.

Parameter recovery. I simulated 300 respondents with 12 tasks each, using known true values. Then I checked if partworth could find them.

Respondent-level 90% intervals covered 88.7% of the true values.
5 of 6 population means and 6 of 6 SDs were inside their 90% intervals.
For the coefficients, the convergence targets were met: R-hat max 1.006, bulk ESS min 1094, no divergences. The correlations are a different story (see below).

Simulation-based calibration. I fitted 200 simulated data sets and looked at 8 population parameters. The smallest uniformity p-value was 0.017. None was below 0.006, the threshold after correcting for 8 tests. So the test found no problem. That is not a proof that the model is calibrated, but it is a useful check.

Speed. On one laptop, 300 respondents took 74 seconds. 1,000 respondents took 290 seconds.

What is not good enough yet

Some targets were not met. I want to list them clearly.

On the camera data, population means differ from bayesm by up to 0.21 of bayesm's posterior SD. My target was 0.1, so this target is not met. The two packages use different priors. When I made partworth's priors much wider, the difference grew to 0.92 SDs. The respondent-level means still correlated with bayesm at 0.998. So, at least on this data set, the population means are sensitive to the priors.
In the recovery test, the price mean (on the log scale) was just outside its 90% interval. The true value was 0.30 and the interval was [0.13, 0.29].
In the recovery test, correlations between tastes mixed slowly. They reached R-hat 1.013 and ESS 399. The targets are R-hat below 1.01 and ESS above 400. Before you report correlations, check their diagnostics. You may need more draws.
In the calibration run, 15 of the 200 fits had a population ESS below 99. That makes the check weaker.
The "Sawtooth-style" files follow Sawtooth's public manuals. They have not been compared with files made by Sawtooth software.
The package is pre-alpha. The API may change. It is not on PyPI yet.

All examples use public or simulated data. The camera data comes from bayesm, which is GPL. partworth never includes that data and uses no bayesm code. The comparison runs R in a separate process.

What is next

The next step is a first release on PyPI. Some things are out of scope: experimental design (use ChoiceDesign for that), latent class, MaxDiff and ACBC.

If you work with CBC data, please try it. Run the Quick look, then examples/camera.py. If you have Sawtooth, I would like to see how its utilities file compares with partworth's. If a fit does not converge, or a number looks wrong to you, please open an issue. Simulated data that shows the problem is the most helpful.

The code, the user guide and all validation reports are here: https://github.com/kojikojikojikoji/partworth

I am Koji Miyazawa, a data scientist living in London. Thanks for reading.

A language app that corrects the sentence you actually wrote

Koji M — Mon, 12 Oct 2026 15:55:39 +0000

Most language apps are good at getting words into your head. Fewer help with the next step: putting those words into a sentence of your own and finding out whether a native speaker would say it that way.

GogaQ is an iPhone and iPad app that my company, Washitsu, makes for that step. You learn sentences grouped by situation, answer in your own words, and get a correction that shows what to delete, what to add and why.

What a correction looks like

Here is a Quick Composition round, with English as the native language and French as the language being learned.

The prompt is "Please send me the documents by tomorrow." Suppose you write Envoie-moi les documents jusqu'à demain, s'il te plaît. It is close, and a French colleague would probably understand it.

In this example, GogaQ scores it 78 out of 100 and marks the one word to change: jusqu'à becomes d'ici. Then it explains why, in English. Jusqu'à demain means "until tomorrow", so the sentence sounds as if they should keep sending documents until then. A deadline ("by tomorrow") needs d'ici demain. A second note covers politeness: Envoie-moi (tu) is fine with a close colleague, while Pourriez-vous m'envoyer (vous) suits a client or your manager. You can listen to the corrected sentence and a more natural alternative, and save it to your review cards.

The correction screen, split into two columns. The app screens in this post were rendered from the app with sample data.

The score measures how far your answer is from the corrected version, so a natural alternative can still lose a few points. What helps more than the number is seeing which word made the difference and why.

The same kind of help runs through free conversation. When you reply to the AI in French, it suggests a more natural way to say what you meant, highlights useful expressions in its own reply, and lets you listen to or translate any line.

Free talk. The shaded line under your message is the suggested rephrasing.

How a session goes

Open the app. Today's plan is waiting on the first screen (more on that below).
Learn sentences by situation. The French sentence book has 2,705 sentences, sorted by situation and CEFR level. You can listen to every sentence.
Answer in your own words, then compare with the corrected sentence and the explanation.
Drill the grammar that tripped you up by arranging words or filling in blanks.
Use it. Free conversation with AI, short compositions with corrections, listening practice, and news articles written at your level with five comprehension questions at the end.

The wordbook is built from those sentences. The French wordbook has 3,611 words, each with its part of speech, meaning and level, and you can save any of them as flashcards.

Keeping track of your study

The Today screen keeps you on schedule. It shows today's phrase, which days you studied this week, your progress toward your daily goal, and today's plan: a round of sentences, a Quick Composition and a syntax drill. Your streak and remaining points sit at the top. The Library shows a "Today's review" count for the cards that are due, so you know when you're caught up.

Left: the Today screen with the weekly record and daily goal. Right: the Library with today's review.

Ten languages, eight native languages

French is one of ten languages you can learn: English, Japanese, Chinese (Simplified), Korean, Spanish, French, German, Indonesian, Vietnamese and Thai. The app itself, including translations and grammar notes, is available in eight native languages: English, Japanese, Chinese, Korean, Vietnamese, Indonesian, German and Thai. Any combination works except learning your own language.

English (CEFR): 2,552 sentences, 6,780 words
Japanese (JLPT): 3,230 sentences, 5,702 words
Chinese, Simplified (HSK): 1,991 sentences, 2,280 words
Korean (TOPIK): 2,011 sentences, 2,448 words
Spanish (CEFR): 2,093 sentences, 2,725 words
French (CEFR): 2,705 sentences, 3,611 words
German (CEFR): 2,100 sentences, 3,053 words
Indonesian (CEFR): 2,111 sentences, 2,617 words
Vietnamese (CEFR): 2,102 sentences, 2,596 words
Thai (CEFR): 2,110 sentences, 2,607 words

English and Japanese come with pre-recorded AI voices, and English learners can choose British, American or Australian accents. The other languages are read aloud by your device's built-in text-to-speech.

What's free

The sentence books and wordbooks don't use points, and they are free with no time limit. The AI features (corrections, conversation, news) run on points. A new account gets 20 points to use within 30 days, which is roughly six AI conversations or ten composition corrections. After that you can subscribe or buy points as you need them. Purchased points don't expire.

Try it

GogaQ runs on iPhone (iOS 18 or later) and iPad (iPadOS 18 or later), and it's free to download:

App Store: apps.apple.com/app/id6762157603
Website (8 languages): gogaq.washitsu-lab.com

If there's a sentence you've never been sure how to say, in French or any of the other nine languages, that's a good one to try first.

Japanese has its own AI tells. I built an agent skill that fixes them.

Koji M — Mon, 12 Oct 2026 13:31:16 +0000

Most of the Japanese I write for work starts as an AI draft: proposals for small businesses, progress reports, Slack updates to people outside engineering. The facts are usually right. I still can't send them as they are, and I kept fixing the same things by hand.

So I turned those fixes into an agent skill and published it. It works with Claude Code, Codex and Cursor.

https://github.com/kojikojikojikoji/natural-japanese-writing

You don't need to read Japanese to use it. You hand the agent a Japanese text and ask it to sound less AI-written.

The problem I kept running into

For a long time I couldn't explain what was wrong. The grammar was fine. A few things that actually happened:

A slide deck for a client still had 御社 ("your company") in six places. It's the spoken form. In writing you use 貴社, and a client notices.
A proposal that executives would sign off on said 「稼働中の版には触れません」, roughly "we won't touch the running version". Engineers get it. The people approving the budget had no idea what it meant for them.
A Slack update to a business team listed file names and line numbers. Nobody on that team opens the repository.

Add the bold "Label:" bullets, the "it's not X, it's Y" lines and paragraphs ending in 「重要です」 ("this is important"). Every time someone pointed one out, I added a line to my CLAUDE.md. The file kept growing and the agent followed it some days and not others.

I tried the English skills first, humanizer and avoid-ai-writing. They look for "delve", "tapestry" and em dashes. On a Japanese report they found almost nothing. So I started collecting Japanese tells from scratch.

How I approached it

Decide who's reading before fixing anything. The skill first labels the text as a business document, casual reading, or a manual. The usual trick for sounding human is to add a personal aside. In a blog post that works. In a proposal to a Japanese client it reads as careless. Without this step, you fix one problem by creating another.

Split the tells into two kinds. Japanese research and measurement posts pointed the same way. Some tells are templates: bold labels, "not X but Y", opening with 「本記事では〜について解説します」 ("In this article, I will explain…") and closing with 「いかがでしたか」 ("How was it?"). Those can be found and deleted. The other kind is evenness: sentence length, sentence endings, paragraph length and comma spacing are all about the same. Human Japanese is lumpier. You can't fix that one phrase at a time, so the skill rewrites the whole paragraph.

Don't convict on one tell. People pick up AI phrasing too, and some "AI phrases" are just normal Japanese. There are 59 tells across six layers. The 25 clearest ones are starred and fixed on sight. The rest are fixed only when three or more different ones land in the same paragraph.

Count what can be counted. An agent reading a checklist misses tells in its own output. So bold text, em dashes, "not X but Y", stock words, repeated endings and sentence-length variance are counted by scripts/check.py (plain Python, no dependencies). After rewriting, the skill runs it again and only returns the text once the starred tells it can count are gone.

What it does to a real draft

I asked a model for a Slack message telling my manager a project is two weeks behind. It returned this (English gloss in brackets):

お疲れ様です。○○プロジェクトについて、進捗が当初のスケジュールから 2 週間遅延 しています。主な要因は以下の通りです。

要件定義の変更 が多数発生し、再設計に時間を要したこと。

外部ベンダーの納品遅延 に伴う依存タスクの遅れ。

リソース不足（開発メンバーの一時的な兼任業務）

現在、遅延分の取り戻しに向けて、次の対策を実施中です。

余裕のあるタスクを再割り当てし、重点的にリソースを集約。

ベンダーと納期再調整を実施し、今後のリスクを低減。

進捗管理を週次ミーティングで細分化し、早期検知体制を強化。

つきましては、新たなマイルストーン案（○月○日完了予定）をご提示いたしますので、ご確認いただけますと幸いです。ご質問やご要望がございましたら、遠慮なくお知らせください。

[The project is 2 weeks delayed. Main factors: 1. Requirement changes … 2. Vendor delivery delay … 3. Resource shortage … Countermeasures: reallocate tasks, re-negotiate with the vendor, strengthen early detection. We hereby present a new milestone proposal and would be grateful for your review. Please do not hesitate to contact us with any questions.]

Five bold phrases in a Slack message to your own manager, bullet points written like slide notes, and a sign-off copied from a customer-service template. After the skill:

お疲れ様です。○○プロジェクトが当初の予定から2週間遅れています。

要件の変更が続いて再設計に時間がかかったことと、外部ベンダーの納品が遅れ、それを待つ作業も遅れたことが主な原因です。開発メンバーの一部は別の業務を兼任していて、人手も足りていませんでした。

今は日程に余裕のある作業から人を外して遅れている作業に回し、ベンダーとは納期を調整し直しています。今後の遅れに早く気づけるよう、毎週の定例会議で進捗を細かく確認するようにしました。

完了予定を○月○日に見直す案をお送りしますので、ご確認をお願いします。

[The project is two weeks behind. Mostly because requirements kept changing and the redesign took time, and because a vendor delivered late, which held up the work that depended on it. Some of the team were also covering other jobs, so we were short-handed. We've moved people off tasks with slack in the schedule onto the late work, and re-agreed the dates with the vendor. To catch future slips earlier, we now go through progress in more detail at the weekly meeting. I'll send a proposal to move completion to [date]. Could you take a look?]

Same delay, same causes, same countermeasures, same request for a new date. Nothing was added. check.py counted six starred tells before and none after.

How you ask changes the fix:

"Rewrite this for the business team": file names and table names become "who is affected and how".
"Make this read like a blog post": the writer's doubts and asides stay in.
Load it before writing: the agent writes to the standard from the start. In my own use that's quicker than fixing afterwards.

Did the tells hold up?

I compared 40 human texts (Slack replies from 14 people) with 40 AI texts (15 everyday prompts such as reports, emails and articles; 15 texts each from Gemini 3.1 Pro and GPT-OSS 120B, 10 from Claude Sonnet 4.6). For each metric I computed the AUC, the chance that a random AI text scores higher than a random human one. 0.5 is a coin flip. Sentence-length variance is lower in AI text, so that row is flipped to read the same way.

Metric	AUC
Starred tells, total	0.91
Bold text	0.89
Sentence-length variance (lower in AI)	0.69
Commas per sentence	0.65
Em dashes	0.51

Some guesses were wrong. The em dash (—), the best-known English tell, barely showed up in Japanese from these three models. And two phrases usually filed under machine-like translationese, 「に関して」 ("regarding") and 「〜することができます」 ("is able to"), were used more by the humans, so I took them off the starred list. The human side is all Slack, which doesn't match the AI prompts and where people rarely use bold, so that number is probably inflated. Details are in eval/README.md.

Install

Claude Code:

mkdir -p ~/.claude/skills
git clone https://github.com/kojikojikojikoji/natural-japanese-writing ~/.claude/skills/natural-japanese-writing

Cursor reads ~/.claude/skills/ too, so that's all.
Codex reads ~/.agents/skills/: mkdir -p ~/.agents/skills && ln -s ~/.claude/skills/natural-japanese-writing ~/.agents/skills/

Then ask: "Make this Japanese sound less AI-written."

It's MIT-licensed. If you find a tell I missed, or Japanese text that slipped past it, please open an issue. I add a line every time someone points one out to me.