Scope and criteria of the 11 rules
This tool adopts a simple inspection mechanism that checks sentences using 11 pre-defined regular expression patterns to assist in proofreading Japanese text.
The inspection items are limited to a total of 11 rules: "dropped 'ra' words" (3 patterns), "double negatives" (2 patterns), "redundant expressions" (2 patterns), "pleonasms/redundancies" (2 patterns), and "inconsistent okurigana notation" (2 patterns).
For example, in the detection of dropped 'ra' words, it targets the appearance of strings such as "見れる", "食べれる", and "来れる", and points out the possible omission of the auxiliary verb "ら".
In the detection of double negatives, it detects euphemistic and complex phrasing that places a cognitive burden on the reader, such as "ないわけではない" and "なくはない", and encourages rewriting them into more concise affirmative expressions.
Redundant expressions target expressions that unnecessarily consume characters, such as "〜を行うことができる" and "〜というふうに". Furthermore, it targets pleonasms with overlapping meanings like "頭痛が痛い" and "一番最初", as well as inconsistent okurigana notation often recommended for correction in business documents, such as "行なう" and "問合せ".
These rules are based on pure string matching and do not involve complex natural language processing such as morphological analysis or syntax tree generation.
Therefore, it does not have the function to interpret the dependency or semantic validity of sentences; it only mechanically determines whether a string corresponding to the 11 registered patterns exists in the input text.
Regular expression matching on the browser main thread
The inspection of the text data input into this tool is entirely processed by the JavaScript regular expression engine running on the user's browser.
Every time a change is made to the text area, the 11 internally held rules (RegExp objects) evaluate the entire input string.
This matching process is executed synchronously on the main thread of the browser, not as a background process using Web Workers or similar technologies.
From the beginning to the end of the input string, it calculates the index positions (start and end positions) where each rule matches, and extracts the corresponding string parts as an array.
If there are multiple matched locations, they are sorted in order of their start positions, and for matches with overlapping areas, the range adopted first is kept and the subsequently overlapping range is excluded after sorting by start position.
It is not a mechanism that always selects the longest candidate at the same starting position.
With this design, a communication process to send text data to an external API server is unnecessary, so the processing is completed within the device.
However, since advanced asynchronous processing is not performed, if an extremely long text exceeding tens of thousands of characters is input at once, or in an environment using older devices, the regular expression evaluation process and the highlight rendering described later may put a load on the browser's operation, potentially causing a temporary input delay.
It is recommended to use this tool with the understanding that the processing system is dependent on the text size and device specifications.
Highlighting matches and providing diagnostic reasons
The string match information extracted through the regular expression matching process is visualized in real-time on the preview screen below the text editor through React component rendering.
Based on the extracted index information, the input plain text is dynamically divided and reconstructed into multiple elements: "normal text parts that did not match" and "highlighted parts that matched the rules."
The highlighted areas are assigned different color codes depending on the rule category (dropped 'ra' words, double negatives, etc.), designed so that the user can intuitively grasp what kind of unnatural expressions are included visually.
When a user clicks on this highlighted area, detailed information about the targeted rule is expanded in the proofreading card area on the right side of the screen.
In addition to the detected string, the proofreading card presents a "diagnostic reason" explaining why the expression was targeted for review.
For example, for the string "を行うことができる", a specific message like "It can be simplified to '〜できる'" is displayed. This message is not dynamically generated, but rather statically defined text linked to each rule in advance.
While it does not have the ability to provide flexible explanations depending on the context, it serves to assist the writer's own judgment by pointing out the typical misuse or reasons for redundant expressions.
Mechanisms and limitations of individual and bulk replacement functions
Among the 11 detected rules, for the 8 rules that have clear alternative expressions (3 dropped 'ra' words, 1 redundant expression, 2 pleonasms, 2 notation fluctuations), recommended "correction proposal" strings are defined within the system.
When these rules are matched, a correction proposal (e.g., "見られる", "頭痛がする", etc.) is displayed along with the diagnostic reason in the proofreading card area, and it is possible to replace the text individually via the "Apply correction" button.
In addition, it features a "bulk correction" function that applies the proposed strings all at once to all replaceable matching locations detected on the preview screen.
When executing bulk correction, the system performs string replacement starting from the match closest to the end of the text. This is a logical control in array manipulation to prevent discrepancies in the indices (start and end positions) of subsequent matching locations due to changes in character count if replacement is performed from the beginning.
This replacement function is designed extremely simply; whether the original context is negative or past tense, the defined single alternative string is inserted as is.
Therefore, it does not properly handle conjugations (for example, when you want to change "〜見れなかった" to "見られなかった"), and there are cases where the connection with the preceding and succeeding particles or word endings becomes unnatural due to replacement with a fixed string.
The replacement function is strictly an auxiliary feature to save input effort, and you must always visually check the surrounding context after application.
False positives due to fixed rules and the importance of review
As mentioned above, the analysis logic of this tool is fixed regular expression matching without morphological or syntactic analysis, so it cannot accurately capture the complex context of natural language.
Due to this specification, "false positives", where expressions match the rules even though they are correct usage, occur at a certain rate.
For example, the double negative expression "〜ないわけではない" is uniformly targeted for a warning as a "roundabout expression" by this tool, but in literary expressions or contexts where it is intentionally used to soften the nuance, the expression itself may be the appropriate expression intended by the writer.
Also, even if strings like "見れる" or "問合せ" are unintentionally included in proper nouns or quotes, the system cannot distinguish the context and will mechanically apply highlights.
In this way, the warnings and correction proposals presented by this tool do not indicate the contextually correct answer. Even if many matching locations are displayed on the result screen, it is not necessary to blindly correct all of them.
Conversely, even if the result is "no matches for the 11 registered patterns," this by no means guarantees that it is a "correct sentence" or that "no typographical errors exist." The detection results should merely be seen as one perspective for proofreading, and the final quality of the text must be ensured by the writer's own review.
How to use this tool in the proofreading process
This tool does not provide comprehensive checks like a professional proofreader or advanced contextual proofreading by AI. On the other hand, it has the convenience and high responsiveness of instantly visualizing specific unnatural expressions just by opening a browser and pasting text.
Considering these characteristics, it is most effectively used as the "first stage of self-checking" in the writing process.
Immediately after writing a text, the writer's memory of what they wrote is strongly retained in their head, so they tend to overlook standard errors such as redundant expressions or dropped 'ra' words.
Therefore, by running the text through this tool as an initial step before having someone else review it or publishing it, you can identify basic formatting irregularities that can be mechanically determined.
For example, by pasting the draft of a blog post or business email into the editor, you can trim redundant parts detected like "〜を行うことができる" into concise expressions and standardize okurigana fluctuations.
After removing the noise from the base text in this way, it is recommended that the writer themselves reads it aloud to check for twisted context, or proceeds to more advanced proofreading tasks like checking for word bias using another N-gram analysis tool.
Positioning this tool as an initial filter in the proofreading workflow serves as a useful stepping stone to streamline the text review process and create text that places less burden on the reader.